From: Jonathan Sergent sergent@io.com

Several things I would say would have changed this a great deal:

-- always make sure you have the latest updates from your distribution
vendor installed (and turn off anything that you know has been broken
but not yet fixed) -- would have eliminated stack smashing possibility

-- use ssh if you are going to su to root. telnet is probably okay for
mortal use. (Just make sure nobody gets in as you and installs a
trojan su! Type "/bin/su" and watch out with your shell init
files.)

-- use a secure hub or switch (aka bridge) so that people can't sniff
much when they try.

Something you didn't mention at all -- turn off .rhosts. You can do
this real easily on PAM-enabled systems in like 30 seconds by taking
the "pam_rhosts_auth" lines out of /etc/pam.d/r{login,sh} [in the Red
Hat case -- will be /etc/pam.conf on other systems like Solaris 2.6].

From: marc_merlin@magic.metawire.com (Marc MERLIN)

>> rpm -qa shows changed binaries.

I messed up however, I meant to say -Va (Verify All)

>- other security problems (/root/.ssh/authorized_keys, mode 666 /etc/shadow,
>setuid copies of shells, etc.) that can be exploited to get root again, but do
>not involve changed binaries that would show up under checksums.

rpm -Va does check file modes (so it would catch /etc/shadow). As for
/root/.ssh/authorized_keys, indeed, there are a few things that you need to
check by hand.

Anyone has a url to a root kit? (so that I could have an idea of what it'd
look like).

From: Mark Willey willey@etla.net

I have been thinking about security lately, and also about the fact that
it's hard to verify your system if it was compromised, as your tools or
the kernel itself may have been hacked. One thing I have been thinking of
is a "security audit" machine that is connected only via a serial port and
does everything thru a login. Although the environment could have been
screwed up and still defeat this. Having this machine share your SCSI
chain with a possibly-affected system would probably work pretty well,
though, as you take the kernel out of the loop, and if you only read from
the (possibly) affected drives, it should be allright. Too bad SCSI
(usually) doesn't support this out of the box. :( Perhaps they will get
it right with Fibre Channel, or NAS (network-attached storage) systems.

Hm, but just wait until we get fancy Network-Attacked^H^H^Hhed Storage that
can be compromised at the *drive's* OS level. ;-)

From: alvin@planet.fef.com (Alvin Oga)

Reposting From: Jonathan Sergent sergent@io.com
....

Several versions, with a variety of licenses...

* The canonical versions are from DataFellows for Windows and Mac and they
are not too bad interface-wise but they cost money (there is a 30-day
trial of some sort) -- http://www.datafellows.com/f-secure/ssh/

* SecureCRT (from http://www.vandyke.com/) is another one you can get a
free trial for.

https://secure.vandyke.com/download/SecureCRT/index.html

* There are some people doing a free one for the Mac whose name and URL
I cannot recall.

* There is a binary-only freeware one for Windows at:
http://www.doc.ic.ac.uk/~ci2/ssh/
that is a bit clumsy but is at the right price for some.

From: Dave Zarzycki dave@c204500-a.frmt1.sfba.home.com

> If you want to avoid sending ftp passwords in cleartext over the net, you
> can use ssh to encrypt your command channel. This will still leave your data
> channel open to all attacks on TCP, and will not work through a firewall.

Of course, if ssh in on both systems, why use ftp at all? what's wrong
with scp?

From: marc_merlin@magic.metawire.com (Marc MERLIN)

>>Tunnel port 21 over ssh.

[...]

If you want to avoid sending ftp passwords in cleartext over the net, you
can use ssh to encrypt your command channel. This will still leave your data
channel open to all attacks on TCP, and will not work through a firewall.

From: Caleb David avatar@very.strange.com

Rick/Everyone else:
Some questions of my own related to this, no intention of stealing
your thread :-) but you reminded me....
...using RH 5.0 with quite a few 5.1 packages installed (maybe all, I
don't recall exactly how much I upgraded from the 'net). Kernel
2.1.107.
I currently have my box set up using tcp_wrappers and everything
denied except what's explicity allowed in hosts.allow (this would be
99.999999% of the planet, the rest being sites I would login from --
work, mostly). I have, as daemons, sendmail 8.8.7, apache 1.3, named,
a mush and a mux (port 4201 and 2000, respectively), and sshd.
I use ssh to login remotely whenever possible, but there are a
couple people/friends who don't have access to an ssh client, so
presumably their passwords could be sniffed out. Neither of them has
anything resembling root access.

Am I totally insane to think that tcp_wrappers are going to prevent
most illegitimate access via normal shell services (telnet, rlogin,
etc)? I realize named is supposed to be a security hole, but I didn't
see on rootshell any mention of exploits using it -- can anyone
elaborate on this? The apache server is about as well locked down as
it can be w/out killing CGI scripts. Sendmail disallows all the Bad
Stuff except for hosts I explicity allow to relay through me.
The mush/mux is irrelevant except for denial-of-service attacks by
means of maxing out the CPU with softcode commands.
It's possible that I have misconfigured ssh somehow, but am
currently under the impression that my sessions are encrypted by
default -- am I wrong here? If so, how do I fix it so they are? And,
what's the difference between sshd and ssh-agent?

Thanks,
Cal

From: marc_merlin@magic.metawire.com (Marc MERLIN)

rpm -qa shows changed binaries.
Then you do a find for suid/sgid binaries, and you check that all of them
are maintained by RPM.

That way:
- You make sure all you existing suid and other root launched programs are
the original ones (if not, just re-install the package, rpm -U --force)
- You also know that you have no other suid backdoors.

From: Rafael Skodlar raffi@kset.com

Hmmm, I am the last one to expect that to happen over there.

I recently exchanged some email about firewalls with somebody who will
likely read this. His position was that others have worse security so it's
going to happen there more likely.

My position is that a firewall is the only way to go....

You can install firewall on on the same machine as it is used for www and
other services or use it in a clasical, 2 interface way.

weenie or not, the damage is there. Time to reinstall the OS, rpm upgrade
wont do it (Marc?).

That's one thing I don't understand in Unix, commercial or free. Why do we
still run applications and programs with unecrypted passwords? That's
crazy! We know for years where the basic security holes are, yet they
still ship old apps/utils. So much time has been wasted because of that.
Why is ssh not a part of RH distribution? If somebody wants to use old
programs they could run rpm to downgrade the system.

RH is not using shadow passwds, not using ssh, sudo, or secure ftp, or...
Why?

> Correct me if I'm wrong: There's no way to secure non-anonymous
> ftp, right? By "secure", I mean prevent disclosure of plaintext

wu-ftp has some of that stuff but there were some bugs in it a few months
back.

From: marc_merlin@magic.metawire.com (Marc MERLIN)

You're saying that you telneted to your machine from some client's site, and
someone was running a password sniffer?

Why not just leave the line out completely?
Like:
bin:*:1:1:bin:/bin:

1) Recompile wu-ftpd to do anonymous ftp only (it's a compilation option
somewhere)
2) Remove users shells from /etc/shells (I think only ftp actually uses
/etc/shells (well chsh also, but you don't use that everyday)).

I do pop3 over ssh, works very well :-)

>5. Allow only APOP; disable the USER/PASS authentication
>mechanism. Qualcomm's qpopper (inherited from Berkeley popper)
>supports APOP: Anybody know how to mandate that auth method
>in qpopper, solely?

If you add users to the apop database, they become forced to use APOP.
Problem with APOP: to my knowledge only eudora supports it (on the windows
side that is, fetchmail does APOP very well also).

[securing ftp]

Tunnel port 21 over ssh.
Another solution is to use a windows ssh client (like SecureCRT) that
supports zmodem. Then, you log in and use good old sz and rz.
The new ssh that was just released yesterday is supposed to work on windows,
_and_ provide scp.

From: Mark Willey willey@etla.net

This can be secured quite easily. Of course you already know about ssh.
If you are in a place with telnet-only access out, you can use S/Key to
provide one-time keys. Under NetBSD, this is as easy as running
"skeyinit". Then I use PilOTP on my Pilot to generate an MD4 hash on
demand and log in.

If you need to su, keep a screen process running in the background with a
root shell. Lock that session with an arbitrary password that you use
only once.

These methods require some work on your part. But I am sure you are
receptive to them, as you just got hacked. :)

I also have other defenses set up. I usually don't talk about it but as
we're among friends... ;-) (And if any o you hack my machine, well, I
can find out where you live.) <evil grin>

Run standard security audit tools, COPS, Tripwire, etc, as well as your
own security scan scripts. Does Linux come with an /etc/security shell
script that runs nightly? Oh yeah, important: *read* the output of the
script. :) Also review your logs. I also have some tools to audibly
announce when certain events happen on my machine.

Now this said, I *do not* believe my machine is secure at all. But I have
tried to remove the easy entries and try to let only trustworthy people on
the machine.

>3. ftp: Under this scenario, I (the sysadmin) can still
>get/retrieve files via _anonymous_ ftp (because I can ssh in
>and su to root) and also via scp (without having to compromise

S/Key can hep you here, too.

From duncan@mail.sfpcug.ORG Sat May 11 19:10:57 1996
Return-Path: duncan@mail.sfpcug.ORG
Received: from atlas.sfpcug.org (atlas.sfpcug.ORG [140.174.70.31]) by hugin.imat.com (8.7.4/8.7.3) with SMTP id TAA11520 for rick@hugin.imat.com; Sat, 11 May 1996 19:10:56 -0700
Received: (from duncan@localhost) by atlas.sfpcug.org (8.6.12/8.6.12) id TAA10953 for tinc; Sat, 11 May 1996 19:06:57 -0700
Date: Sat, 11 May 1996 19:06:57 -0700
From: Duncan MacKinnon duncan@mail.sfpcug.ORG
Message-Id: 199605120206.TAA10953@atlas.sfpcug.org
To: tinc@atlas.sfpcug.org
Status: RO

>From agate!brain.cs.berkeley.edu!genehkan Mon Mar 25 02:13:59 1996
Path: agate!brain.cs.berkeley.edu!genehkan
From: genehkan@brain.cs.berkeley.edu (Gene Kan)
Newsgroups: ucb.os.linux,ucb.org.callug
Subject: Minutes for Linux Security Talk, Ian Goldberg, 031996
Date: 20 Mar 1996 21:18:39 GMT
Organization: Cal Linux Users Group
Lines: 156
Message-ID: 4ipsnf$qb4@agate.berkeley.edu
NNTP-Posting-Host: wakko.cs.berkeley.edu
Xref: agate ucb.os.linux:960 ucb.org.callug:237

From: Linda Kamas kamas@eecs.berkeley.edu
Annotated and modified by Gene Kan, 03/20/96

Linux Security Talk 3/19/96
===========================

Presenter: Ian Goldberg

Threat Models
-------------
Set perimeters of trust around your computer--physical, over network
connections,intra-group.

#1 common reason for a break-in is for others to use your computer's
resources.
Ex: Use your hard disk for stolen software
Use your CPU cycles for passwd cracking
Use your identity to disguise attacks on other computers

This is what will be discussed.

Where to Get Info
-----------------
newsgroups:
comp.security.announce (low volume)
comp.security.unix (high volume)

lists:
linux-security
linux-alert
enroll by mailing to majordomo@linux.???
type "subscribe linux-security" in body of email to enroll in linux-security.

Book:
"Firewalls and Internet Security: Repelling the Wily Hacker" by
William R. Cheswich and Steven M. Bellovin

What to Check
-------------
Listed below are important commands to see what your machine is doing
and configuration files to edit to make your machine more secure.

1. ps -auxw
Look at all processes that are running and be familiar with them.
Typical programs running as root:
inetd
crond
sendmail
getty (the login prompt which asks for passwords)
Programs that must run as many users must run as root.

2. netstat
See who is connected to your machine.
tcp ex: telnet, rlogin need reliable connection
udp ex: nfs doesn't register errors

ports < 1024 are run by root
port 2049 is NFS connection, oddly enough.
unix sockets are relatively benign, they are connections within
your computer.

Advice: don't run NFS if you want security.

3. lsof -i
This command is not necc. available with linux installation, you'll
need to get this off the net.
This shows the internet connections of all files.

What you may see:
inetd this is where security holes probably are.
this program is run at boot time and initiates
root internet service programs.
example inetd internally provided services: time, echo

advice: turn OFF all network services that you won't be using,
(ex: turn off ftp and telnet if you will not be telnetting/
ftping TO your computer)

specific advice: turn OFF systat and netstat. You don't need others
using this to find out about your machine. (NOTE: the default
mode of these programs is enabled.)
If you don't use pop2 or pop3 (to pop your mail from home to
somewhere else) disable these.

how to execute the advice: edit the /etc/inetd.conf file by commenting
out services that are unnecessary. All internet services are
governed by a line in the inetd.conf file, with a corresponding
service -> port mapping in /etc/services. It is good practice
to run as few services as root as possible since each service
program could potentially have bugs which lead to security holes.

advice: set the user of inetd executed as the user "nobody". This is
one of the fields in the inetd.conf config lines. You can choose
to have processes run as any user, but only those processes which
MUST run as root should be run as root, since that promotes
security holes.

4. The program tcpd is good (you don't run this, root does).
This only lets users from computers x connect to your machine and
partake in services y.

advice: edit /etc/hosts.allow and /etc/hosts.deny to allow/deny
certain hosts and certain services. Put all your tcpd programs
in hosts.deny for more security.

the format of /etc/hosts.{allow, deny} is
service: hosts
foo: ALL (good default for a hosts.deny file)

the tcpd manpage is well-documented. Read it.

5. Another file to edit is /etc/rc.d/rc.inet2 (maybe something else in redhat)
Comment out programs you do not need to run.
advice: keep backups of the original files. If you do screw up, keep boot
and root disks handy. To boot in single-user mode (may need this)
type:
boot: linux single

MORAL: Be familiar with what network services you are running.

Other Advice
------------
.rhosts are bad

Use kerberos and ssh.
kerberos = program with services like ftp (kftp) and rlogin (krlogin)
but tickets encrypted by passwd are sent over the net for
confirmation rather than passwds.
ssh = secure shell

Most probable security risks:
httpd
sendmail
lpd

Configuration files (those listed in previous section: rc.inet2, inetd.com)
that are world writeable is a BAD idea.

Testing your System
-------------------
Satan tests security on your machine. Only run satan on your own machine.
Be root on another (a friend's) machine and run satan against your machine
from there.

Check your syslog for unusual activity. tcpd logs any usage of programs?
network services? in a syslog file and lists by whom they were used. There
is not very much accounting going on in Unix systems, so you are kind of
limited as to what you can figure out, but overall, the netstat and lsof
utilities provide you with some amount of help.
--
Gene
* .stack a with it do programmers Forth
* http://ucsee.eecs.berkeley.edu/~genehkan