logging - "secure" logs don't tell me who is logging in?

logging - "secure" logs don't tell me who is logging in?

Post by Greyblad » Sun, 01 Oct 2000 04:00:00



All,

A few weeks ago I was hacked, and at around the same time my
"/var/log/secure*" logs stopped indicating who is logging in thru telnet or
ftp.  Before that time it always gave me the user name.  I have not been
able to figure out how to get this working again.  Please help!

Bill

 
 
 

logging - "secure" logs don't tell me who is logging in?

Post by Joe Schaefe » Sun, 01 Oct 2000 04:00:00



> All,

> A few weeks ago I was hacked, and at around the same time my
> "/var/log/secure*" logs stopped indicating who is logging in thru telnet or
> ftp.  Before that time it always gave me the user name.  I have not been
> able to figure out how to get this working again.  Please help!

> Bill

You need to check your settings in /etc/syslog.conf- something like

auth,authpriv.*         /var/log/secure

should be there.  

However, if you were hacked, you should assume that your syslogd
daemon, inetd, ipchains, kernel, netstat, ls, ps, top, and basically
every other binary on your system has been modified by the cracker.  
Take your box offline, backup your /home directory and whatever else
you've modified (no executables, though- just data files),
then reformat all your partitions. Now reinstall, disable all unnecessary
services, setup your ipchains (with a lot of logging rules since you've been
hacked once), and bring it back online.

You've a busy weekend ahead of you.

Best.

--
Joe Schaefer

 
 
 

logging - "secure" logs don't tell me who is logging in?

Post by Grega Brem » Sun, 01 Oct 2000 04:00:00


...and Greyblade used the keyboard:

Quote:>All,

>A few weeks ago I was hacked, and at around the same time my
>"/var/log/secure*" logs stopped indicating who is logging in thru telnet or
>ftp.  Before that time it always gave me the user name.  I have not been
>able to figure out how to get this working again.  Please help!

Hi, Bill,

you might want to take a look at your /etc/syslog.conf file, and see
to it that somewhere in there, logging of facility "auth" (or
"security", which is an alias for it) is enabled at all levels.

Just how it is done depends on the technique used to enable logging in
your syslog.conf, but usually it looks like that:

auth.<somelevel>      /var/adm/somefile

where <somelevel> is one of the valid syslogd levels: debug, info,
notice, warning (warn), err (error), crit, alert and emerg (panic).

Do note that logging of the auth. facility can also be enabled
implicitly, using a wildcard that logs everyting of a given priority
(and possibly above):

*.info                      /var/adm/somefile

would log everything of level info and above to /var/adm/somefile,
whereas

*.=info                     /var/adm/somefile

would log everything of only level info to /var/adm/somefile.

For a detailed explanation of syslog.conf peculiarities you might want
to take a look at the manual page, "man 5 syslog.conf".

The other possibility is that in /etc/login.defs, logging of
successful logins has been disabled. See "man 5 login.defs" for exact
information on how this is done on your distribution (because it tends
to vary), but it might look like so:

LOG_OK_LOGINS           yes

There are also some other options in login.defs that relate to login
logging (logging login :-)), albeit only to failed logins and
superuser activity:

FAILLOG_ENAB, LOG_UNKFAIL_ENAB, SYSLOG_SG_ENAB, SYSLOG_SU_ENAB, ...

These are the only two configuration-related options that I can
remember off the top of my head (and there is PAM, but I'm definitely
not acquainted to it enough to even have a hint of whether or not
there are logging options in it, let alone be telling you about it),
but if you didn't reinstall your system after being hacked, there is a
very real possibility that some of your programs have been replaced
and this lack of logging is simply one of the (less harmful, might I
add) consequences of that. See to it that you back up all of your data
and wipe-out-everything/reinstall your system if that was the case.

Cheers,
--
    Grega Bremec
    grega.bremec-at-gbsoft.org
    http://www.gbsoft.org/

 
 
 

1. "Logging" or "Log structured" file systems with news spool.

(I've included comp.arch.storage and comp.databases in hopes of getting
info from people who know about large file systems with lots of small
files).

We're putting together a new news machine since our old one, which was
a large general server is going to be retired in a few months.  Instead
of burdening our newer servers with news, we want to set up a
workstation (Sparc 5 w/Solaris 2.4) dedicated to news.

I figure that anything I can do to speed up disk performance in the
news spool disk is worth a fair amount of effort.  News is pretty close
to a worst case scenario for disk performance due to the small files
(3.5KB average, 2KB typical) and the fact that news requires tons of
random seeking.  I'd like to plan this system so that it can easily
handle the news load for several years as well as support about 100
readers.  Right now my news spool contains about three-hundred-
thousand files and I expire news after 5 days.

I plan to move to the INN transport software with this new news server.

I've been researching things and I believe that using a log structured
file system (provided by Veritas Volume Manager) can probably buy me
some extra performance, particularly during news reception (lots of
small writes).  Is this correct?  I believe Sun's Online: Disksuite 3.0
provides a logging UFS.  Might this increase performance if I decide
not to use Veritas for some reason?

Also, we'll be using multiple 1GB disks.  I suspect that using multiple
disks with large stripe (interlace) sizes will also be a win since
individual articles end up on one disk or another but not spread over
each except for the relatively rare large article.  I'm hoping this
will reduce the individual seeking that has to be done on each disk.
Even if it doesn't buy me any performance (though I hope it will) I'm
hoping this will at least reduce wear on the disks by distributing the
workload.

I'd appreciate any comments or advice on this subject.

--Bill Davidson

2. GCC Install help

3. UFS logging VS Solstice DiskSuite's Trans metadevice "UFS logging"

4. getting page up/down to work

5. userdel : "user" is in use, but "user" isn't logged

6. after installation no icons in kde3

7. Log reporting: for "big" logs

8. Controlling Network Usage

9. Logging stopped on RH 5.2 (no output to "messages" log)

10. secure logs of /var/log/secure

11. Can't get Snort to log to /var/log/secure

12. /var/log/secure doesn't log hostname

13. Is there a way to tell who "logged in" to your web page?