>On Mon, 8 Apr 1996, Dan Hollis wrote:
>
>> I would prefer something like strong authentication and encryption (Kerberos,
>> SSL). It is still possible to spoof IP addresses and get around access
>> control systems like tcpd. And logging IDENT/TAP is pretty useless as well
>> considering most ident/tap systems allow you to set the username and
therefore
>> lie.
>  I work for an ISP, and we will be implementing SSL on our internal
>machines.  I see your point about IDENT.  I will say, however, TCPd has
>saved our behinds many a times.  It has caught and rejected well over 100
>hacking attempts.  We've recently been getting telnet and pop server
>connect attempts from a site it cannot determine an IP address for, which
>has me concerned (possible spoof attack?) but has also been apparently
>keeping that out as well.
 
The errors you are most likely seeing are:
 
"Cannot connect to host : endpoint not connected"
 
   and
 
"Unable to resolve address : endpoint not connected"
 
This most likely is not a hack attempt. It is most likely misconfigured DNS
on the remote end. (Besides, hackers don't usually bother with POP.)
 
How do you know it saved your ass if nothing happened, and you aren't sure if
they were hack attempts or not?
 
>tcpd is a champ, coupled with the securelib
>package.  I haven't heard anything good on Kerberos, so I've never really
>given it a shot.  One of my co-workers doesn't think too highly of it.
 
Yes, but has he _used_ it? Sounds to me like the people who put down Unix
all the time, but when you ask them if they've ever used it, the answer is
generally "no, but I heard from XXX that..."
 
>Since we are an ISP, to do DES and Kerberos authentication for over 1500
>users would be senile... the wrappers perform well to reject suspicious
>connections.  On a smaller scale I see that perhaps Kerberos would be more
>fit.
 
Most packages (SSL, etc) are trivial to implement. Laziness is never an
excuse.
 
Kerberos was designed to be scalable, it is designed for large sites (e.g.
universities) because other authentication mechanisms don't scale well.
 
>> I'd rather prevent someone from getting in the door in the first place,
>> rather than logging their attacks after they have been made.
>  Wrappers provide, IMHO, a second level of security.  If your router is
>flooded, either internally or externally, and the filters start to fail,
>it would be nice to have something on the host side to start weeding out
>material. If your filters break, then you would be dead.
 
The normal behavior of routers when they get flooded is to drop packets.
So the scenario you gave above will simply never happen. Router filters don't
"leak" under load.
 
>If you forget one small little thing on a perimeter host, then you are also
>dead in the water.
 
This is a different situation entirely. However it's just as easy to flub up
tcp wrappers.
 
Read "Internet Security : Foiling the wily hacker" or some such title. It
has a lot of good information on this including the golden rule : KEEP IT
SIMPLE. A properly configured firewall system should be so simple as to be
nearly impossible to flub up.
 
If you configure your firewalls to "default reject" and only selectively
allow access, then you are less likely to cause a security hole by
'forgetting' to add a host.
 
>> Stuff like kerberos/SSL is nearly impossible to spoof. (Not 'impossible',
>> just 'nearly impossible' :-)
>  But, you need encryption libraries to support, keys, client/server
>software, and it can be very CPU intensive.
 
Depends on what you're encrypting. Telnet is not generally CPU intensive.
And what is CPU time compared to network security. CPU time is cheap in
comparison to cleaning up after a successful cracker.
 
>> If you have a proper firewall and proxy system you would not have to care.
>> They wouldn't be able to get to your system in the first place. (And if you
>> configured the proxy to log that information, you'd still have an 'audit
>> trail' although as I said before it would still be next to worthless.)
>  If you firewall everything, then why be on the Internet or a WAN in the
>first place?
 
Because a properly configured firewall will deter all but the most determined
hackers.
 
>Any "out-of-the-box" machine, no matter how firewalled on sensitive ports, can
>be broken.
 
This is true, and keep in mind physical access is also an issue. If someone
can walk in the door and hook a PC up to your lan and sniff it, you're
screwed. Look at the real problems, not the imagined ones. Internal security
is much more important than external security since internal attacks generally
come from informed sources, e.g. employees and ex-employees.
 
The only secure computer is an unplugged one in a concrete vault at the
bottom of the marianas trench. And even then, I wouldn't bet my life on it :-)
 
>Without a second level of security, offline logs, etc., a hacker behind a
>firewall is basically home free.
 
If they got behind the firewall, then you're screwed anyway since tcp wrappers
are as I said not useful for authentication. If he spoofed his way past the
firewall he can spoof his way past the wrappers even easier.
 
>Logs,
>although "after the fact" will tell you where the entry occurred so that
>you can fix it for next time.  To prevent tampering with logs, it is good
>to have them go offline (my HP 3000 will serve in this respect... I just
>redirect log output to a serial connection to the non-networked HP which
>catalogs it, perhaps using IMAGE in the future for a database).
 
Another good undefeatable logging method is a good old dot matrix printer :-)
Although a serial connection to an unconnected host is also good.
 
A warning:
 
If you are depending on tcp wrappers to do all your "security" for you, you
are only fooling yourself. tcp wrappers are most useful for logging and maybe
'tar baby' cracker traps, but as an authentication mechanism they are next
to useless.
 
-Dan
.----------------------------------------------.
|Dan Hollis -- Pharmacy Computer Services, Inc.|
[log in to unmask]      -     (503)476-3139|
`----------------------------------------------'