The argument that netcat shouldn't be used or doesn't have value in a network environment because its detected by AVs is specious to say the least. I agree completely with the statement that FTP and Telnet are dead protocols, if what was meant that they are dated and there are better solutions.

I still fail to see why you would want to add an administrative overhead to an environment and I highly doubt that there is value to be gained by managing a switch or device using netcat over telnet.  Unless you are security I highly doubt that a tool commonly associated with an attacker would be used by the network group and to then whitelist that tool you are now opening up the potential for that tool to go unnoticed in your environment.

When would I need to process raw traffic using netcat in the context of this discussion? I though the idea was to replace telnet using netcat?

The only thing in this case that netcat may be better for is wrapping in a script and at that point you'd be better off in cleaning up your environment and using ssh.

Why would a person condone the use of a tool that is known to be used by attackers on a network? I don't disagree that it is a great tool, I've written about it's uses and still use it a lot, but to allow a tool like that to be used outside of the context of security then that is irresponsible especially in a large environment where managing those tools and their use becomes more difficult.

Again i don't disagree that SSH should be used for device management tasks but in most large organizations, regardless of the industry, you will find that due to the number of legacy apps and the sheer number of devices that it's no small task to even attempt an upgrade of that sort throughout an organization.

This goes back to my original point that while Telnet is not ideal it is sometimes a necessary evil and if the risk posed by having it in use is one that is acceptable...

As vijay2 said defense in depth is standard procedure in most places. It's often easier to limit telnet access to a management ip range and vlan or to implement ACLs at the edge or even in the distribution layer to prevent certain protocols or to implement and ids/ips than it is to move to using a more secure protocol. If the attacker is on the network and has access to the management network then other controls would have had to have failed first.

While your tone leaves a lot to be desired i don't disagree with either you or Grendel but the fact remains that implementing certain replacement protocols can be a logistical nightmare in large organizations. Most of my clients are orgs with 10k-40k employees and i often see in their environments what this whole thread has been about. When asked why it's left that way I find that the answer is generally the same. Resources need to be allocated to projects and projects are prioritized according to risk and based on the additional controls in place the risk is not severe.

As for the 'scary' tools you mentioned. Yes, they have a place in any environment and do bring value. But to propose a tool that is detected by AV over one that is not and your answer to that is to whitelist it in the AV?? I fail to see the logic. i have a problem with a blanket statement like that. I'm going to assume that he meant that the enterprise AV in use was configured so that only his and a few other select systems were whitelisted or perhaps he runs it in a vm. Either way perhaps qualifying that statement would have saved some time.

As to the admin being owned. My argument was not that the admin using the tool would be owned but that if such a tools use was commonplace in the network then perhaps its use would be overlooked when it was not legitimate.

Yes, I agree with both the above posts and I was attempting to acknowledge environmental variables. I just have a problem with blanket statements like "The argument that a person should use netcat over telnet or ftp is absurd."  Every network will be different and might be subject to different regulation. For instance, if an admin feels his network is too unwieldy or perhaps his skill level isn’t up for the challenge then perhaps the only safe solution is a more generic approach.
 
I am sure we would all agree that in some environmental circumstances the use of tools like netcat would be acceptable and in others it might not be appropriate.  If we claim to be hackers as well as network admin and not some “cant think outside the box” corporate suit , being intelligently flexible is a desirable quality and this approach reflects that. Just my 2 cents.

I think dean has brought this up several times:


Don

There was a fantastic tool called 'hunt' which would sniff for telnet sessions and then hijack them. Great fun for typing stuff into other peoples terminal windows! This was in the days of shared network media and easy to guess TCP sequence numbers (windows 95 on 10BASE2 coax). If telnet was outdated and insecure then it sure as hell is now.

Jimbob