Re: Did I give up on telnet too easily?

From: Juhana Siren (Juhana.Siren_at_oulu.fi)
Date: 09/25/03


Date: 25 Sep 2003 14:27:07 +0300

Alan Connor <alanconnor@earthlink.net> writes:

> All that is required is a little common sense: monitor the ports open to
> connections, log them (packets), and be prepared to dump a file of infinite
> length containing all the ascii characters, non-printing too, on anyone getting
> intrusive. Optionally, to run a very harsh and intrusive 'nmap' on them.

Over here the latter might land you in jail.

So, you're essentially suggesting the equivalent of transporting
bundles of cash (=potentially valuable information) in plain view in a
pickup truck (=unencrypted) and trying to make sure nobody notices it
while it's in the parking lot (=roaming around the net for everybody
to see)?

> This can be scripted and/or manual. I've caught someone sniffing around a
> few times. It doesn't take much to scare them off.

So you either install a car alarm (but leave the money out in the
open) or keep an eye on the truck while in the grocery store? While
someone takes the cash and runs?

> Why do all IP professionals assume that everyone else is ignorant
> and that fancy new programs provide better security than the
> sensible use of relatively simple tools that have withstood the test
> of time because they WORK?

Because of comments like this :)

Telnet works: you can get from point A to point B with it. However,
everything you transmit is essentially public information. If someone
has cracked a switch and listens to your traffic, you may not even
notice it. Your packets simply get copied along the way. However, if
everything is encrypted, it's useless to the listener.

If you have a closed network where you *know* nobody is listening
(i.e. you know *exactly* who is allowed on the network, you know that
you can trust them, you know that they are *not* compromized *and* you
know that *there is no inward access from elsewhere*) there's no harm
in using the traditional tools - unless you suspect that one of your
internal users may be malicious...

> The fact is that security loopholes are primarily caused by complexity in
> programs: Stout doors and expensive locks will do more to actually protect
> your house than fancy alarm systems.

Now you're contradicting yourself. Earlier you wrote about your fancy
alarm systems and how they help secure your unencrypted connections.
Now you say alarm systems won't help.

IMNSHO, to maintain an alarm system around an unencrypted connection
to ensure nobody is listening is complex because of the multitude of
ways to eavesdrop unnoticed. To encrypt the connection to ensure that
any data captured is useless for a long time without proper
credentials is simple, or at least simpler than the former, even if
the algorithm is relatively complex.

About the 15 second file-creation window: ARGH. What if someone
attacks with a script that takes control of the entire machine in the
15 seconds? A script can do plenty more than you in 15 seconds. It
doesn't take a script that long to gain root, install and start a
backdoor daemon, and cover its tracks before being thrown out. If you
really want to use one-time authentication tokens, consider SecurID or
equivalent products, not some idiotic (sorry, but that's my opinion!)
home-made kludge.

There are enough crackers as it is, please don't make their life any
easier.

-- 
****** Juhana Siren ***** Juhana.Siren@oulu.fi ***** OH8HTH (2 m, 70 cm) ******
        --Buddhist at a hot dog stand: "Make me one with everything."--


Relevant Pages

  • Re: Did I give up on telnet too easily?
    ... Your packets simply get copied along the way. ... If you have a closed network where you *know* nobody is listening ... alarm systems and how they help secure your unencrypted connections. ...
    (comp.os.linux.security)
  • Re: Did I give up on telnet too easily?
    ... Your packets simply get copied along the way. ... If you have a closed network where you *know* nobody is listening ... alarm systems and how they help secure your unencrypted connections. ...
    (comp.os.linux.security)
  • Re: not listening
    ... nothing listening on any port. ... Nothing listening for *new* connections on any port, ... but you sure have something listening for returning packets. ...
    (comp.security.firewalls)
  • Re: Panic @r207433: "System call fork returning with the following locks held"
    ... panic: sleeping thread ... data packets ... connections established ... hdac0: attempting to allocate 1 MSI vectors ...
    (freebsd-current)
  • TCP Connections, Bluesocket, and Mac OS X
    ... concerning OSX systems and Bluesocket wireless technology. ... due to too many open network connections. ... You can see how many sessions your ... 18908 data packets ...
    (alt.internet.wireless)