IT Commandment: Thou shalt not use nonsecure protocols on thy network

IT Commandment: Thou shalt not use nonsecure protocols on thy network

Summary: You may have noticed recent posts from some of the ZDNet bloggers in a series we're calling IT Commandments. Here's mine: Turn off Telnet and FTP and use secure protocols to provide access to your network.

TOPICS: Networking

it_command.gifYou may have noticed recent posts from some of the ZDNet bloggers in a series we're calling IT Commandments. Here's a commandment for any of you responsible for administering your company's network: Turn off Telnet and FTP and use secure protocols to provide access through the firewall.

Telnet and FTP are two of the oldest net protocols and they date back to a simpler time when script kiddies, bots, and viruses were theoretical problems, not everyday facts of life. If you have responsibility for protecting your network, data, and users from all of the badware, and the bad people who create it, operating on the public network, you need to close as many ports on your firewall as possible and exercise control over who and what gets inside.

How you do this is less critical than that you do it. Many organizations use a Virtual Private Network (VPN) to create a secure tunnel through the firewall. The recent proliferation of SSL-based VPNs has eliminated a lot of the cost and complexity of this approach. As the ability to present application-level capabilities in the browser continues to mature, these less expensive VPNs will continue to grow in popularity compared to solutions that use proprietary clients.

Secure Shell (SSH) is another option. Whether you use OpenSSH, the open source implementation of the protocol bundled with virtually every *NIX operating system (including Mac OS X) or a commercial alternative, SSH2 (the current protocol standard) is a software-only alternative that provides encryption, authentication, and data integrity to data through a single port on your firewall. SSH2 provides remote access, file transfer, ad data tunneling services. (Disclosure: In my "day job" I work for VanDyke Software which develops, sells, and supports SSH clients and servers for Windows and a variety *NIX platforms).

There are other approaches. Small businesses and free agents often use something like GoToMyPC to access a desktop PC while on the road or at a client site. Microsoft offers a Small Business Server (SBS) bundle which delivers a lot of value for a relatively small investment to smaller organizations. SBS includes Exchange Server, SQL Server, and Windows Server 2003, all of which have the ability to enforce authentication using encrypted passwords, digital certificates, and other methods.

As I said, it matters less how you do it than that you do it. Providing unfettered access to your network or allowing protocols that send unencrypted data are risks you simply cannot afford. If you do need to provide public FTP access, put that server outside your firewall in a DMZ and access it using a secure connection from inside your network. Restrict Telnet use to inside the firewall only if you must use it. Tunnel all TCP/IP application data through a VPN or SSH connection.

Finally, explain your security policies in plain English to every user on your network. Security shouldn't be a black art or the sole province of network administrators. Phishing and other social engineering techniques can compromise the best technology decisions you can make. educate your organization about why security is so important and how every person can help to reduce the availability of a human vector to potential attackers.

Go forth and be secure.

Our IT Commandments:
  1. Thou shalt not outsource mission critical functions
  2. Thou shalt not pretend
  3. Thou shalt honor and empower thy (Unix) sysadmins
  4. Thou shalt leave the ideology to someone else
  5. Thou shalt not condemn departments doing their own IT
  6. Thou shalt put thy users first, above all else
  7. Thou shalt give something back to the community
  8. Thou shalt not use nonsecure protocols on thy network
  9. Thou shalt free thy content
  10. Thou shalt not ignore security risks when choosing platforms
  11. Thou shalt not fear change
  12. Thou shalt document all thy works
  13. Thou shalt loosely couple

Topic: Networking

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Turn of HTTP while you're at it!

    Funny, it seems to me that the VAST MAJORITY of severe virus/spyware/adware problems flowed over HTTP! How about this: dump the idiot Web-based applications, and enforce a strict "deny all" policy on the router for HTTP. It is interesting when you look at it, every employee in a company at most will have 3 - 10 "must access" web sites to do their job, with a few exceptions. Give them access to what they need, and that is IT. If you must, insist that every Website a user visits not on the "allow list" MUSt be SSL encrypted. When was the last time you heard of outbound telnet or FTP being used as an attack vector? It is pretty rare.

    Gee, all of a sudden, I think this might not happen in any company...

    Get real. If you are so concerned about your network security, block HTTP for anything outside the Intranet. Don't think turning off protocols like Telnet & FTP, that only a handful of users use (and how many of them are sending passwords to your network on those outbound connections?) while leaving HTTP wide open will help in the slightest. The real problem is people like the ZDNet Web 2.0 cheerleading squad who think that the real answer to everything is HTTP based. You've traded one unsecured application for another. And nobody got a virus simply by pointing their Telnet or FTP client to the wrong host.

    Justin James
    • Filtering HHTP is a good idea but...

      Turning it off is unreasonable. Are you going to tell a company that they cannot allow their users to do web-based research, connect to the web sites of customers, partners, and competitors?

      A well-configured proxy is a great layer in any network defense but your solution is a bit draconian for most organizations.

      And you miss the point about Telnet and FTP. It's not the outbound traffic that's the issue so much as the inbound traffic. We live in a world where the workforce is increasingly mobile and/or distributed in a number of locations. There are also telecommuters to contend with. And, whether you realize it or not, about 50% of organization we surveyed last year are still using Telnet and FTP in their organizations (this number is backed up by surveys done by SANS and other organizations.

      I agree completely that web-based applications should be secured by SSL or some other method. Personally, I use an SSH tunnel to get to my copany intranet when I'm working from home or on the road so everything I send (and receive) is encrypted and I know I am actually talking to the right host. Man in the middle attacks can not take place if you connect to network resources via a host that has to authenticate to you as well as you to it.

      Badware needs to be addressed with a lyered defense as well. Anti-* applications and a tight firewall are layers an organization that takes security seriously should enforce. Mandating the use of two-factor authentication by policy is another to prevent passwords from being compromised.
      • SSH tunnel