Very Computer

  My machine was cracked into recently, and from what I can piece
together, the crackers managed to look into /tmp, find a file that was
left accidentally containing the password to a trivial account, got in
and then pulled some silly trick with Cron involving mail. The thing
that confuses me most is how they were able to look into /tmp. Anonymous
FTP isn't allowed and I can't think of any other possible way they could
have gotten in.
  Any help you can provide me in this area will be greatly appreciated.

Ed Ryan

Unless you have good evidence to show this is how they got it, it is
more likely that they exploited some program with a known bug, (or
possibly sniffed passwords from a local network).

It's rather difficult to trace these things down, but if you want
to you should start by looking carefully at your log files. If you
think they may have had access to the machines as root then you
should remember that the logs may have been tampered with.

(Also, you should consider reinstalling if they may have had access
as root).

        David.

Are you sure you were cracked?

The default setup enables "cron" and attempts to run several things from
/etc/crontab including scripts named "daily", "weekly", and "monthly"
which, by default, do not exist.  When that time rolls around and cron
tries and fails to run these scripts, it sends mail to root.

Comment them out in /etc/crontab.

John David Galt

  Well, I've figured out mostly what happened. They sniffed the password
of one of my users and were using the machine benignly for several
months. We only caught on because one of my assistants saw them as they
were logged on. They had been keeping all of their stuff in an innocuous
subdirectory of ~/mail of the user.
  Fortunately, it doesn't seem they ever got root, because they would
then have changed the logs to help keep me from catching on.
  In any case, I've started making use of hosts.allow (I have a small
enough number of users to make this feasible) so I doubt there'll be any
more trouble from them.

Ed Ryan

Yes, this is often a key question.  While not wanting to make people
(especially those unused to administering remotely-accessible systems)
less concerned with security, the fact is that most "I was cracked"
reports on this newsgroup turn out to be incorrect.  In this case,
though, I think it's reasonable to assume as a starting point that the
original poster knows whether his system was cracked or not.  The
question is how they got access, and the poster was right that there
shouldn't be any way to see /tmp from outisde the machine.

Quote:> The default setup enables "cron" and attempts to run several things from
> /etc/crontab including scripts named "daily", "weekly", and "monthly"
> which, by default, do not exist.  When that time rolls around and cron
> tries and fails to run these scripts, it sends mail to root.

Aside from the fact that cron is enabled by default, this is
incorrect.  There used (*years* ago) to be scripts by those names, but
they have not been called by the default crontab since they were
removed.  What *is* called is a script called "periodic" (which has
its own man page, incidentally), and which is called with *parameters*
of "daily", "weekly", and "monthly" (as appropriate).  In a default
installation, the periodic script *does* exist as called from the
default crontab, and it in turn invokes scripts in
/etc/periodic/{daily,weekly,monthly} as appropriate.  There shouldn't
be any missing scripts resulting in errors, but there *will* be mail
reporting the results of the periodic checks.

Quote:> Comment them out in /etc/crontab.

I can't go along with this.  If the problem is that the cron entries
are broken, the right answer is to fix them -- this problem has not
been widely reported, and is presumably a unique case of pilot error.
If, as this poster has indicated elsewhere, the problem is a
philosophical opposition to *any* pre-existing cron entries, that is a
different matter.  The person who owns the system can, *of course*, do
anything he wants with it.  But disabling periodic still isn't good
advice to give to novices.

Be well.

You're wrong.  I found these calls in crontab on my own system, installed
in January from the 3.3-RELEASE CDs.

Quote:> What *is* called is a script called "periodic" (which has
> its own man page, incidentally), and which is called with *parameters*
> of "daily", "weekly", and "monthly" (as appropriate).  In a default
> installation, the periodic script *does* exist as called from the
> default crontab, and it in turn invokes scripts in
> /etc/periodic/{daily,weekly,monthly} as appropriate.

Maybe that's where the scripts are supposed to be, but crontab does not
include any paths, just "daily", "weekly", and "monthly".

Quote:>> Comment them out in /etc/crontab.

> I can't go along with this.  If the problem is that the cron entries
> are broken, the right answer is to fix them -- this problem has not
> been widely reported, and is presumably a unique case of pilot error.

This is like blaming Netscape's security holes on "user error".  In both
cases the software, when first installed, should do nothing the user
hasn't explicitly told it to do.  Any other default setting is a bug in
the release, not a user error.

John David Galt

Quote:>>> The default setup enables "cron" and attempts to run several things from
>>> /etc/crontab including scripts named "daily", "weekly", and "monthly"
>>> which, by default, do not exist.  When that time rolls around and cron
>>> tries and fails to run these scripts, it sends mail to root.

>> Aside from the fact that cron is enabled by default, this is
>> incorrect.  There used (*years* ago) to be scripts by those names, but
>> they have not been called by the default crontab since they were
>> removed.

> You're wrong.  I found these calls in crontab on my own system, installed
> in January from the 3.3-RELEASE CDs.

And if you look closer, you'll see that the way the script is
actually called is:

# do daily/weekly/monthly maintenance
59    1     *     *     *     root    periodic daily 2>&1 | sendmail root

which says: at the 59th minute, of the 1st hour on every day run the command
"periodic" with the paramter "daily".

The periodic script (/usr/sbin/periodic) then calls the scripts in the
directory /etc/periodic/{daily|weekly|monthly} as the case may be.

There is no actual script called daily, weekly, monthly anymore.

This was checked on several of my machines rangeing from 3.2 to 3.4-RELEASE.

Mark.

With all due respect (a quantity that, to be honest, your actions are
not causing to increase), I was correct and you were wrong.  While I
don't have the 3.3-RELEASE crontab at hand, I have the one from 3.1,
and it is in no way substantially different from the one in -STABLE.

The entry in question is as follows (I take the weekly one as a
demonstration, but the daily and monthly examples are precisely
analogous):
30      3       *       *       6       root    periodic weekly 2>&1 | sendmail root

The
"30      3       *       *       6"
part means that this runs at 3:30 on Saturday morning.

The
                                       "root"
part means that it runs as root.

The rest is the command line that is executed as the root user at
3:30AM every Saturday.
"periodic weekly 2>&1 | sendmail root"

This means that a command called "periodic" is executed with a
parameter of "weekly", its standard error is redirected to standard
output, and the standard output is mailed to the root user.  Note that
the word "weekly" in there is not the name of a script, or any other
kind of "call" as you put it, but is rather a "parameter" (that is,
it's information that is provided to the command, rather than a
command itself).  

"periodic" is implemented as a script in /usr/sbin, and the way it
uses the parameter is to find a subdirectory within the /etc/periodic
directory of that name.  There is no script called "weekly" anywhere
on the system, nor is there any "call" to such a script in the crontab.

Quote:> > What *is* called is a script called "periodic" (which has
> > its own man page, incidentally), and which is called with *parameters*
> > of "daily", "weekly", and "monthly" (as appropriate).  In a default
> > installation, the periodic script *does* exist as called from the
> > default crontab, and it in turn invokes scripts in
> > /etc/periodic/{daily,weekly,monthly} as appropriate.

> Maybe that's where the scripts are supposed to be, but crontab does not
> include any paths, just "daily", "weekly", and "monthly".

That's incorrect, as I explained above.  The *path* to the command is
set up at the top of the crontab, in a line that begins "PATH=" and
which sets the search path that will be used to find commands within
the crontab.  The path to the scripts that are run on a daily, weekly,
and monthly basis is found in /usr/sbin/periodic, although additional
ones can also be specified in rc.conf.

Quote:> >> Comment them out in /etc/crontab.

> > I can't go along with this.  If the problem is that the cron entries
> > are broken, the right answer is to fix them -- this problem has not
> > been widely reported, and is presumably a unique case of pilot error.

> This is like blaming Netscape's security holes on "user error".  In both
> cases the software, when first installed, should do nothing the user
> hasn't explicitly told it to do.  Any other default setting is a bug in
> the release, not a user error.

That's a philosophical point, and one that makes a lot of sense on a
machine that does not support remote access (for example, MS-DOS, or
an Etch-a-Sketch).  I happen to disagree, for systems like FreeBSD
that offer networked services by default, but there's room for
argument on this one.  [For example, there could be an installation
option that doesn't run *any* daemons at startup -- no crontab, no
inetd, etc.  But I think more people would be confused about why they
couldn't FTP to this system than would be happy about the security
implications.]

However, your original explanation of how these things were, in your
words, "broken," was completely incorrect, and you are attempting to
change the topic here off of your misguided factual claims.  Because
many novices read this newsgroup, you are doing a grave disservice to
FreeBSD by continuing to post responses to other peoples' questions
that have been sufficiently offbase as to mislead novices and require
correction from more experienced people.

 - Lowell Gilbert