Image
 
Latest Additions
 
EH-Net Login
Welcome Guest.






Lost Password?
No account yet? Register
Who's Online
We have 29 guests and 5 members online
EH-Net Donations

Enter Amount:
$

Google Ads
ChicagoCon 2008f
chicagocon2008f_125x200banner.jpg
ChicagoCon 2008f
EH-Net News Feeds
Latest Additions
Book Recommendations





 
Advertisement

You are here: Home arrow Forum arrow Ethical Hacking Discussions and Related Certificationsarrow Network Pen Testingarrow Telnet/FTP Security Question
Ethical Hacker Community Forums
September 05, 2008, 11:34:08 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Registration Now Open for ChicagoCon 2008f Oct 27 - Nov 2! Visit www.chicagocon.com.
 
   Home   Help Calendar Login Register  
Pages: 1 [2]   Go Down
  Print  
Author Topic: Telnet/FTP Security Question  (Read 663 times)
0 Members and 1 Guest are viewing this topic.
sgt_mjc
Full Member
***
Offline Offline

Posts: 118


View Profile
« Reply #15 on: Yesterday at 03:13:35 PM »

Symantec puts a lot of our tools on the auto-quarentine list. I had all kinds of problems with getting Cain & Able on more work computer. The guys who handle our AV (Symantec) had to set up a group, make me a member of that group, and I still had to place the tools to not be scanned in that location. Of course, I have not had this problem at home with my AV. Go figure?Huh
Logged

Mike Conway
CompTia Security +
C|EH
Kev
Sr. Member
****
Offline Offline

Posts: 309


View Profile
« Reply #16 on: Yesterday at 03:32:56 PM »

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.
Logged
Grendel
Newbie
*
Offline Offline

Posts: 10


View Profile WWW
« Reply #17 on: Yesterday at 03:36:19 PM »

Symantec puts a lot of our tools on the auto-quarentine list. I had all kinds of problems with getting Cain & Able on more work computer.
Yeah, so did I - my solution was to use a VM to get around the AV.
Logged

ISSMP CISSP SCSECA SCNA SCSA IAM MSCS MSM
dean
Full Member
***
Offline Offline

Posts: 130


View Profile
« Reply #18 on: Yesterday at 03:37:42 PM »

If you were using Netcat as an administrative tool this wouldn't be a problem because you could exclude Netcat from the AV.

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.
Logged

<script>alert('%52%54%46%4D')</script>
Grendel
Newbie
*
Offline Offline

Posts: 10


View Profile WWW
« Reply #19 on: Yesterday at 03:53:42 PM »

Quote
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.  

I would rather use the best tool for the job, and if that means going through hoops, so be it.

Quote
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?

Telnet has a nasty habit of intercepting characters it considers to be commands intended for the telnet application, thus corrupting the data stream.  Also, it will inject data into the stream as well.  With netcat, none of this happens - what you see is unadulterated.

When dealing with a switch, you won't see much difference using telnet over netcat.  However, once you proceed pass simple shell account access activities, netcat really shines.  As to the use of netcat within the context of this topic, I did state outright that the use of netcat was a tangent to this discussion.  Sorry if you thought I implied it was related to the discussion... my bad.

Quote
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.

If all we're talking about is shell access, than I will definitely fall back to the original argument that ssh should be implemented.
« Last Edit: Yesterday at 03:55:14 PM by Grendel » Logged

ISSMP CISSP SCSECA SCNA SCSA IAM MSCS MSM
dean
Full Member
***
Offline Offline

Posts: 130


View Profile
« Reply #20 on: Yesterday at 09:50:40 PM »

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.
Logged

<script>alert('%52%54%46%4D')</script>
Kev
Sr. Member
****
Offline Offline

Posts: 309


View Profile
« Reply #21 on: Yesterday at 11:06:17 PM »

I agree completely with Grendel's thoughts on this.  To disregard a tool because its either too much trouble to implement or it sets off an AV or OMG it’s known to be used by hackers is not a valid approach in my humble opinion.  I know a number of very skilled admins that use netcat in their network environment as well as other  scary “hacker” tools like nmap, nessus, etc… without any issues what so ever. Why?  Well, they are really on top of their security and have everything locked down very tight.  Any extra activity from a dreaded hacker tool will be discovered quickly.  Obviously an AV is not the only thing in place to monitor activity.  However, making generic statements regarding the security of any network can be dangerous. Each situation is different as well as the level of skill of those that have the responsibility of maintaining the flow of the network.  Having said that, if tomorrow I get a call from one of these admins saying he got breached because he allowed the use of netcat (I highly doubt it), then I will obviously change my opinion, lol. 
« Last Edit: Yesterday at 11:08:03 PM by Kev » Logged
dean
Full Member
***
Offline Offline

Posts: 130


View Profile
« Reply #22 on: Today at 12:12:31 AM »

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.
Logged

<script>alert('%52%54%46%4D')</script>
vijay2
Full Member
***
Offline Offline

Posts: 111


View Profile
« Reply #23 on: Today at 06:17:54 AM »

Well, again I would point out that with this whole discussion for netcat and telnet in my humble opinion is we are comparing apples to oranges, the 2 tools are great in their own right but they are functionally different. All you can get with netcat is a shell access not and a terminal access. And there is a huge difference between shell access and terminal access.

With only shell access you cannot run editors like vi, or you cannot pivot to another machine using ssh or telnet to another machine from a shell or  ftp or sftp or scp for that matter from a shell. These basic things might be small things but for me I would like to have the ability to do these basic stuff when i have access to that machine.

Also, if i own a machine the first thing i would look for on that machine is netcat, which is not installed by default on windows and most Linux versions have limited functionality. Therefore, i would not want to leave a copy of netcat on my machines and give the attacker one up on me, specifically on my admin machines.

Agreed that netcat is a wonderful and most powerful utility, but has its limitations.

Just my 2 cents

VJ
Logged

GCIH CISSP GSEC OSCP C|EH MCSE CNE Security+
Kev
Sr. Member
****
Offline Offline

Posts: 309


View Profile
« Reply #24 on: Today at 09:03:03 AM »

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.
« Last Edit: Today at 09:29:33 AM by Kev » Logged
Pages: 1 [2]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.5 | SMF © 2006-2008, Simple Machines LLC
Joomla Bridge by JoomlaHacks.com
Valid XHTML 1.0! Valid CSS!
Page created in 0.055 seconds with 23 queries.
 
Polls
Best for daily desktop use:
 
Support EH-Net
chicagocon2008f_125x200banner.jpg
ChicagoCon 2008f


Support EH-Net by
Buying all of your
Amazon items using
the search bar above.

cbtnuggets_logo_125.jpg
Try CBT Nuggets Free!
Recent Forum Topics
Vote For EH-Net

progenic.com
Click here to Vote!

Sadikhov.com
Top IT Cert Sites

binarica.com
Binarica Logo

Add to Technorati Favorites
technorati fave

chicagocon2008f_125x200banner.jpg
ChicagoCon 2008f
 
         
Advertisement

© 2008 The Ethical Hacker Network
Joomla! is Free Software released under the GNU/GPL License.