Home page logo
/

educause logo Educause Security Discussion mailing list archives

Re: SYSADM and Security
From: Russell Fulton <r.fulton () AUCKLAND AC NZ>
Date: Thu, 4 Jan 2007 17:58:24 +1300

We too have separate groups for OS administration PS administration and
DBAs. I believe that all the special PS accounts such as sysadm are set
up so they can not be logged into directly.  All admins and DBAs have
individual logins (soon to be controlled via RSA tokens) and users then
'sudo su' to the special accounts.

We have central log processing and I have lists of the logins for DBAs
and admins and anyone su-ing to to something they should not will raise
a flag in the hourly report.

Eventually I'll do a daily report of all authentication/authorisation
logs for each machine.

here is an excerpt from the log processing config and should give some
idea of what I'm doing:

Note the regular expressions are Ruby REs -- more or less the same as Perl.

# this section tries to cover all the legit su and sudo activity

$ITSS_UNIX_ADMIN = (?:xxxx|yyyy|zzzz|....)
$ITSS_DBA = (?:aaa|bbb003|ccc007|...)
$PS_ADMIN = (?:ggg002|hhh210|zzz028|...)
$PS_ACC = ps(?:hr|fs|sa|ep|admin)(?:prd|tst|dev)?

[service itssunixadmin] {
  [periodic] {
    proc sudo &
/^$ITSS_UNIX_ADMIN/                                      : drop
    proc sudo & %r!^$PS_ADMIN .* COMMAND=(?:/usr)?/bin/su -
$PS_ACC!             : drop
    proc sudo & %r!^$ITSS_DBA .* COMMAND=(?:/usr)?/bin/su -
(?:oracle|vdxt)!     : drop
    proc sudo & %r!nobody .+ COMMAND=/bin/cat
/proc/megaide/0/status!        : drop
    proc su & /'su $PS_ACC' succeeded for
$PS_ADMIN/                         : drop
    proc su & /'su (?:oracle|hyperion)' succeeded for
$ITSS_DBA/             : drop
    proc su & /'su root' succeeded for
$ITSS_UNIX_ADMIN/                     : drop
    proc su & /'su \w+' succeeded for
root/                                  : drop
    proc su & /^'su $PS_ACC' succeeded for
$PS_ADMIN/                    : drop
    proc su & /^'su weblogic' succeeded for
$PS_ADMIN/                   : drop
    proc login & %r!^?ROOT LOGIN
/dev/pts/\d+!                           : drop
    proc sshd & /^Accepted keyboard-interactive for
$ITSS_UNIX_ADMIN/    : drop
    proc sshd & /^Accepted password for
$ITSS_UNIX_ADMIN/                : drop
    proc sshd & /^Accepted publickey for $ITSS_UNIX_ADMIN from
130\.216\./       : drop
    proc sshd & /^Accepted publickey for oracle from
192.168\.163\.(5|8)/        : drop
    proc sshd & %r!^'su root' succeeded for root on
/dev/\?\?\?/            : drop
  }
}

Log record that are not dropped are reported hourly.
The root logins are from console logins as part of the VM management and
are (I'm told) unavoidable.

Mark Staples wrote:
I've been wondering what other institutions are doing about system
accounts (i.e. sysadm with PeopleSoft) that have full administrative
access and can be used by any DBA, which then impacts effective
monitoring and accountability.

I'm being told that there is no way around the regular use of these
type of accounts and I need to accept the risk and trust our DBAs.
While I "believe" what I'm being told, I'd like to find out what other
institutions are doing to address the use of system accounts.

Thanks!

Mark


-----
Mark Staples
Director of Information Security/Chief Information Security Officer
IT Research Liaison
Medical College of Georgia
Office: 706-721-1577
FAX: 706-721-7296
mstaples () mcg edu

--------

All information in the communication, including attachments, is
strictly confidential and intended solely for delivery to the
addressee(s) identified above (ie, To/cc/bc), and may contain
privileged, confidential, proprietary and /or intellectual property
entitled to protection from disclosure under applicable law.  If you
are not the intended recipient, please take note that any use,
distribution or copying of this communication is unauthorized and may
be unlawful.  If you have received this communication in error, please
notify the sender, delete this correspondence from your computer, and
destroy any printed copies of this communication.
------------------------------------------------------------------------

BEGIN:VCARD
VERSION:2.1
N:Staples;Mark
FN:Mark Staples
TITLE:Chief Information Security Officer
ORG:Medical College of Georgia
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;1120 15th Street=0D=0AHS-2125;Augusta;GA;30912;USA
ADR;HOME:;;P.O. Box 1505;Augusta;Georgia;30903;USA
URL;WORK:http://www.mcg.edu
TEL;WORK:706-721-1577
EMAIL:mstaples () mcg edu
TEL;CELL:706-799-7409
TEL;FAX:706-721-7296
END:VCARD



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault