You are here: Home / Blog / Why firewalls don’t have Telnet or SSH Clients

Why Firewalls Don’t Have Telnet or SSH Clients

13th May 2011 by 15 Comments

I found this on a blog:

Another missing ASA-feature: telnet and ssh client: “ Every single decent Cisco-device on earth has the ability to make an CLI-user jump to another device with telnet or ssh. Except the ASA. I really wish that this feature could be added. Right now I am troubleshooting a firewall and from where I am right now the only way in is to SSH to the ASA. I can do whatever I want inside the firewall from my SSH-window, but I need to access a router inside of that firewall, and if this feature wasn´t missing i could simply run ‘ssh ip-address’ to jump to the switch´s CLI.

Am I the last CLI-.guy on this planet? Please, Cisco?

My Answer:

The general view from the “security industry” is that implementation of telnet / SSH clients onto firewalls creates unacceptable security risk. This is because the use of client can be used to effectively bypass the firewall – that is, a user can SSH into the firewall, then SSH out from the firewall and then represents a security breach under most corporate security policies.

Because all firewalls are submitted to various standards bodies that agree that such things should not be allowed, most firewalls do not have telnet clients. Look at the Common Criteria Portal for more information.

However, some firewalls are allowing the functionality, for example Juniper NetScreen has a default setting of off, but you can enable in recent versions. From http://kb.juniper.net/InfoCenter/index?page=content&id=KB13890

Telnet client on the Juniper firewall is supported starting with ScreenOS 6.2.0 and above.
Previous versions of ScreenOS do not include a Telnet client; therefore, you cannot Telnet from the CLI of a Juniper firewall using firmware 6.1.0, 6.0.0, 5.4.0, etc. See KB5887.

Commands to enable/disable the Telnet client:

set telnet client enable
unset telnet client enable

I don’t know if Cisco has any plans to offer this feature.
(Via Jimmys Cyber Corner.)

Filed Under: Blog, Netscreen, Operation Tagged With: , ,
About Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus

  • http://lbdigest.com Tony Bourke

    I don’t even need Telnet/SSH really, I typically use telnet as a generic TCP connection tester. If they added a generic layer 4 testing utility, that would probably take care of 90% of what people want Telnet for.

    • Peter Van Eynde

      Recent ASA versions (8.4 and above) have “ping tcp”:

      http://www.cisco.com/en/US/docs/security/asa/asa84/command/reference/p.html#wp2133619

      demonstration for working/failed:

      bsns-asa5505-27# ping tcp inside 10.48.66.200 22
      Type escape sequence to abort.
      No source specified. Pinging from identity interface.
      Sending 5 TCP SYN requests to 10.48.66.200 port 22
      from 10.48.67.51, timeout is 2 seconds:
      !!!!!
      Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
      bsns-asa5505-27# ping tcp inside 10.48.66.200 900
      Type escape sequence to abort.
      No source specified. Pinging from identity interface.
      Sending 5 TCP SYN requests to 10.48.66.200 port 900
      from 10.48.67.51, timeout is 2 seconds:
      RRRRR
      Success rate is 0 percent (0/5)

      (full disclosure: I work for Cisco)

      • http://www.iggdawg.com/blog Ian

        As Tony mentioned, this is exactly what most of security people wanted out of telnet on an ASA. Just to reach out on an arbitrary port for no other reason than to see if it connects or not for the purposes of troubleshooting. I was so happy to see this when i read the 8.4 release notes. So much so that i decided to take the plunge and deal with the new NAT system just to get the TCP ping tool.

    • Adam Stuart

      ASA 8.4 adds tcp ping:

      “TCP ping allows users whose ICMP echo requests are blocked to check connectivity over TCP.
      With the TCP ping enhancement you can specify a source IP address and a port and source
      interface to send pings to a hostname or an IPv4 address.
      We modified the following command: ping tcp.”

  • http://smallpayroll.ca Sean

    Check Point FW-1 still enforces the policy on locally originated connections, which I think is the proper way to do it if you’re going to offer the feature (which I always found helpful).

    Sean

  • Lindsay

    I agree with Tony – it’s not really about logging into something, it’s about doing that quick “telnet IP” to check the service is actually running. I’ve lost count of the number of “firewall problems” that I’ve bounced back because the service isn’t actually running.

    Check Point SecurePlatform doesn’t ship with a telnet client, but it’s easy enough to add one. Sean’s right – the correct thing to do is to enforce policy on outbound traffic, and log/deny as required.

  • Pingback: Cisco ASA firewall lacks an telnet/ssh client — Jimmys Cyber Corner

  • http://blogg.kvistofta.nu Jimmy Larsson

    Hi there!

    Greg, I have updated my blog post to respond to your post above. Please comment in any way, I love discussions like this!

    http://blogg.kvistofta.nu/another-missing-asa-feature-telnet-and-ssh-client

    /Jimmy

    • Ferro Greg

      In my post I specifically referred to SSH Server and Telnet Server being different from SSH Client and Telnet client. Inbound connections for SSH management are mandatory, SSH Clients for outbound connections are a potential security breach because there is no prevention of abuse by privileged staff.

      greg

  • Justin

    Jimmy,
    The differences between being able to SSH to a FW and SSH from a FW are significant.

    Being able to SSH to a FW is required for management. Having access from outside the FW is a security risk that most accept. It is better if you can restrict the outside access to a list of known static IPs.
    Being able to SSH from a FW, on the other hand, is substantially riskier to the rest of the network as Greg pointed out. If someone is able to gain access to the FW, then they would be able to use the tools on the FW to probe or gain access to the rest of the network as the FW. This would bypass any other security you might have in place like restricting SSH access to your routers from all but internal IPs.

    Justin

  • Sam Stickland

    I second Tony’s statement!

  • Paulie

    How I get around this last week was to VPN through the firewall, then ssh into the switch on the other side of the ASA then ssh back from said switch. It lost OSPF between them so could only connect to the firewall remotely via the locally connected subnet. Why it lost the neighborship, it seemed like an arp cache issue, clearing didn’t help, but driving in and replacing the cable did.

  • https://twitter.com/verbosemode Jochen Bartl

    I agree that a hardened system should have only necessary software installed. But I don’t think a SSH or Telnet client is a security risk. If an attacker was able to access the firewall the game is already somewhat lost. He could just configure port forwarding and access hosts behind the firewall via telnet/ssh that way.

    A better approach to deal with this risk would be to install a packet filter, which prevents the firewall itself from connecting back to the internal network.

    • Ferro Greg

      You need to consider both directions, inbound AND outbound. Providing a path in or out of the network by telnet or SSH isn’t acceptable for most organisations. That’s why it’s not part of the code.

  • Martijn

    Nice discussion, but some things don’t add up. Basically, there are 2 scenarios here:
    - attacker gains ssh access into the firewall. Game over, period. Absence of an ssh client doesn’t even matter if the attacker can modify rules.

    - administrator accesses the firewall through ssh, wants to ssh into the interior network. 2 options: allow (and log perhaps), or don’t allow and reduce the admin’s effectiveness. The presence of an ssh client merely enables the admin to work more effectively, nothing more.

    If it’s against policy, the firewall shouldn’t have an ssh client. If it’s not, the presence of it does not increase the security risk by much, if at all. Just make it an optional install and be done with it.