OS account report - Security

This is a discussion on OS account report - Security ; Does anybody know of an existing script/package to generate a report like this: We need a copy of an OS account audit report. This report will include a status review of all currently open accounts on all Linux systems, when ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: OS account report

  1. OS account report

    Does anybody know of an existing script/package to generate a report
    like this:

    We need a copy of an OS account audit report. This report will include
    a status review of all currently open accounts on all Linux systems,
    when those accounts were activated, who created them, what they are
    allowed to access, and what their privilege levels are.

    We have 200 linux servers so obviously we need a way to automate
    this.




  2. Re: OS account report

    Chris Cox wrote:
    > On Sun, 2008-03-16 at 21:41 -0700, mom wrote:
    >> Does anybody know of an existing script/package to generate a report
    >> like this:
    >>
    >> We need a copy of an OS account audit report. This report will include
    >> a status review of all currently open accounts on all Linux systems,
    >> when those accounts were activated, who created them, what they are
    >> allowed to access, and what their privilege levels are.
    >>
    >> We have 200 linux servers so obviously we need a way to automate
    >> this.

    >
    > Well... what mechanism do you use to automate the creation of users
    > across those 200 hosts? You need to hook your accounting into that.
    > With regards to the past, if you were not tracking who did what
    > as root... there's no good way of doing that for the past.
    >
    > Privilege levels in *ix are site defined (mostly). Btw, they are
    > site defined (mostly) in Windows now as well, just that most
    > are clueless about it.
    >
    > So... the truth is... can't be done (by default).
    >
    > However, you can tweak your own processes and security
    > policies to enable some of this kind of tracking for
    > future build outs.


    Note that this only works if you create accounts *only* with a managed tool.
    When you have local admins able to create local accounts, and systems such as
    normal /etc/passwd that don't timestamp accounts, you have a real problem.


  3. Re: OS account report

    Nico Kadel-Garcia wrote:
    > Chris Cox wrote:

    ....
    >> However, you can tweak your own processes and security
    >> policies to enable some of this kind of tracking for
    >> future build outs.

    >
    > Note that this only works if you create accounts *only* with a managed
    > tool. When you have local admins able to create local accounts, and
    > systems such as normal /etc/passwd that don't timestamp accounts, you
    > have a real problem.
    >


    This is why I said this can only be controlled by your own
    "processes and security policies".

    What's the best way to keep cars from colliding at an intersection?

    1. Don't drive anymore.
    or
    2. Come up with rules and traffic signs/signals (which people can
    break, if they want to end up in the hospital).



  4. Re: OS account report

    Chris Cox wrote:
    > Nico Kadel-Garcia wrote:
    >> Chris Cox wrote:

    > ...
    >>> However, you can tweak your own processes and security
    >>> policies to enable some of this kind of tracking for
    >>> future build outs.

    >>
    >> Note that this only works if you create accounts *only* with a managed
    >> tool. When you have local admins able to create local accounts, and
    >> systems such as normal /etc/passwd that don't timestamp accounts, you
    >> have a real problem.
    >>

    >
    > This is why I said this can only be controlled by your own
    > "processes and security policies".
    >
    > What's the best way to keep cars from colliding at an intersection?
    >
    > 1. Don't drive anymore.
    > or
    > 2. Come up with rules and traffic signs/signals (which people can
    > break, if they want to end up in the hospital).


    And don't forget:

    3: Take the car away from anyone who doesn't follow the rules, whatever the
    rules happen to be.

    It's that last part which can be very difficult in a mixed environment. Old
    NIS tools, for example, that pubolish UID's below 500 are hell to manage in a
    mixed environment. Linux's NIS servers handle the publication limitation well,
    most other operating systems do not, including the inventors of NIS, Sun.

    Many casual open source authors include a 'useradd' for a specific username in
    their installation tools, such as 'apache' for the Apache server, 'nagios' for
    Nagios, etc. This breaks down badly if the 'useradd' failes to specify
    low-numbered UID's, as backup and account management get confused.

    Really, you have to mandate the use of a central system to keep them
    synchronized and prevent conflicts. This is an artform!

+ Reply to Thread