SCIENTIFIC-LINUX-USERS Archives

May 2010

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Steven Timm <[log in to unmask]>
Reply To:
Steven Timm <[log in to unmask]>
Date:
Thu, 6 May 2010 10:34:19 -0500
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (128 lines)
On Thu, 6 May 2010, Larry Linder wrote:

> On Wednesday 05 May 2010 17:03, g wrote:
>> Larry Linder wrote:
>>> Sometime in the last few weeks I have lost the ability to add new users.
>>> I get an error message that passwd and shadow are different.  Ran
>>> "pwconv" same error mesage and it flages gpasswd and gshadow are
>>> different.
>>
>> not good.
>>
>>
>>  1) record date and time of all passwd and group files. backup these files
>>     and all log files off of system.
> The orig. file dates were 15 Jan 10 and new dates were 5 May 10.
> I may have clobbered the date while fixing a few errors.  Such as missing : 's
> Hate to be paranoid but could these be some one foot print.
>
> There are a number of logins that were added since install.
> piranha:x:60:60::/etc/sysconfig/ha:/sbin/nologin
> luci:x:101:104::/var/lib/luci:/sbin/nologin
> ricci:x:102:105:ricci daemon user:/var/lib/ricci:/sbin/nologin


piranha, luci, and ricci are all part of legitimate redhat packages,
all having to do with various high-availability stuff including LVS.
Nothing to worry there.

Steve


>
>
>
>>  2) if you have slightest thought of a system breech, change root and *all*
>>     admin passwords now and maintain them.
> I noticed that the allowable root user in group contained another name.  So
> someone else is of group root.
>>  3) check logs to see who was logged in and who was root, su-root, or admin
>>     during time.
> Unfortunately I had just removed old logs during quarterly clean up.   I have
> plenty of disk space but old habits die hard.
>>
>>  4) any updating going on during time?
>>
>>  5) open and check passwd and shadow, and group and gshadow files and
>> compare order of listing. they should match in order.
> They didn't and date was 15 Jan 10.
>
>>  6) carefully check passwd and group files to be sure that what is listed
>> is what should be.
> The above passwd and groups contained the above entries see 1.
>
>>  7) ensure that all names have 'x' in 2nd position and that only root has
>>    '0' in 3rd position of passwd file and that all users are 500 and
>> higher.
> If you notice that there were a number of pw entries that has different no in
> 3rd and 4th col.  Only suspect entries have what is a cross linked login.
>
>>  8) ensure that only root and users have an encrypted password shown. rest
>>     should be '*' or '!!'. programs that are 'user' should have '*', system
>>     files should have '!!'.
>>
>>  9) ensure that in group file, all listed have 'x' in second position.
> All have "x" in second entry.
>
>> 10) ensure that in gshadow, root and common groups should have nothing in
>> 2nd and 3rd positions, 4th position who is allowed.
> In gshadow there are a number of user accounts that have !! in second
> position.
> Are these from malformed group.
>
>> ounce above is done, go back thru group and shadow match any miss ordering.
>> same for group and gshadow, and correct any incorrect users.
> There were a number of differences when using "diff" that I looked right but
> were out of order?
>> something bad wrong caused this problem and it may be a fluke. but it could
>> be caused by and unhappy user or a system breech.
> There are several other system abnormality:
> 1.   When you are saving a file there is a slight hesitation - like processor
> is taking a nap.   This happens when using Opera to look at hardware files on
> internet.
> 2.  System log has a repeating message.
> "engr01 kernel: spurious APIC interrupt on CPU#0, should never happen.
> 3.  This system started having a problem with a print server.  I may send one
> file to printer on print server and that is it.  Leaves an unterminated file
> message in CUPS.  All other systems can print to this server with out an
> issue.
>
>> there is a site with this information in more detail, but i can not find it
>> in my bookmarks.
>>
>> i will search for it again and post when i find it.
>>
> Thanks for the help.  It looks like someone has been into a number of systems.
> Backup Server looks pretty clean.   The affected boxes can be accessed from
> users home.  The access is vi "ssh" and "ftp".   Some like to work odd hours
> due to family issues.
>
> Histroy:
> In 2002 our system got a virus that attached its self to every file at the
> 4096 byte boundary.  Inserted an 8K block of code that looked for ???
> It spread over the entire network in a few minutes.   We had to disconnect all
> boxes on our network, disconnect them from the internet, format disks and
> reinstall all sw.   Even the back ups were infected.  The team worked 18 to
> 20 hours a day for a week.
> Fortunately we did not loose any engineering data files.
> Until we found out what was causing the problem we were a day from turning off
> the power, locking the doors and walking away.
> We then got serious about security and loadable SW.
>
> If I ever met a person who claimed to have written a virus I would give him a
> frontal lobotomy with my LouisVille Slugger.
>
> Thanks for help.
>> much luck.
>>
>>
>> later.
>

-- 
------------------------------------------------------------------
Steven C. Timm, Ph.D  (630) 840-8525
[log in to unmask]  http://home.fnal.gov/~timm/
Fermilab Computing Division, Scientific Computing Facilities,
Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader.

ATOM RSS1 RSS2