Vraag Log alle opdrachten in die worden uitgevoerd door beheerders op productieservers


Het is het beleid van het bedrijf voor beheerders om zich aan te melden bij de servers via een persoonlijke gebruikersnaam en vervolgens uit te voeren sudo -i om root te worden. Bij het hardlopen sudo -i, sudo maakt een omgevingsvariabele genaamd SUDO_USER, die de gebruikersnaam van de oorspronkelijke gebruiker bevat.

Is er een manier om in te loggen? ALLEMAAL opdrachten in syslog met iets dat lijkt op de volgende syntaxis:

${TIME/DATE STAMP}: [${REAL_USER}|${SUDO_USER}]: ${CMD}

Een voorbeeldingang zou zijn:

Sat Jan 19 22:28:46 CST 2013: [root|ksoviero]: yum install random-pkg

Uiteraard hoeft het niet exact de bovenstaande syntaxis te zijn, het hoeft slechts een minimum van de echte gebruiker (bijvoorbeeld root), de sudo-gebruiker (bijv. Ksoviero) en de volledige opdracht die werd uitgevoerd (bijv. installeer random-pkg).

Ik heb het al geprobeerd snoopy, maar het bevatte niet de SUDO_USER variabel.


61
2018-01-20 04:35


oorsprong


Jij hebt nodig auditd. - Michael Hampton♦
Dit is een korte intro voor auditd - Deer Hunter
Kan iemand dit als een antwoord plaatsen? Geef aan hoe ik alle opdrachten die door gebruikers worden uitgevoerd strikt zou loggen. Het "korte intro om te auditeren" was nuttig, maar het bevatte niets dat gerelateerd was aan het loggen van de werkelijke commando's (voor zover ik het toch kon zien). - Soviero
Ok, ik ben begonnen met spelen auditd, en hoewel ik het heb gekregen om alle opdrachten te loggen die worden uitgevoerd, bevat dit niet de SUDO_USER variabele (of gelijkwaardige informatie), en ik kan geen manier vinden om het op te nemen. Alle hulp wordt zeer op prijs gesteld! - Soviero
En wat zal het bedrijf doen do met deze record van alle opdrachten die zijn ingevoerd door beheerders? - ewwhite


antwoorden:


Bijwerken: Nog 2 dingen die zijn opgedoken in de opmerkingen en in vervolgvragen:

  • Gebruik makend van auditd op deze manier zal uw logvolume drastisch toenemen, vooral als het systeem zwaar wordt gebruikt via de commandoregel. Pas uw logbestand voor logboekbewaring aan.
  • Auditd logboeken op de host waar ze zijn gemaakt, zijn net zo veilig als andere bestanden in dezelfde box. Stuur uw logbestanden door naar een externe logboekverzamelserver zoals ELK of Graylog om de integriteit van uw logboeken te behouden. Plus, toe te voegen aan het punt hierboven, laat het toe om meer agressief oude logs te verwijderen.

Zoals gesuggereerd door Michael Hampton, auditd is hier de juiste tool voor de klus.

Ik heb dit getest op een Ubuntu 12.10-installatie, dus je kilometers kunnen op andere systemen verschillen.

  • Installeren auditd:

    apt-get install auditd

  • Voeg deze 2 regels toe aan /etc/audit/audit.rules:

    - een exit, altijd -F arch = b64 -F euid = 0 -S execve
    - een exit, altijd -F arch = b32 -F euid = 0 -S execve

Deze zullen alle commando's volgen die worden uitgevoerd door root (euid=0). Waarom twee regels? De execve syscall moet worden bijgehouden in zowel 32- als 64-bits code.

  • Zich ontdoen van auid=4294967295 berichten in logboeken, toevoegen audit=1 naar de cmdline van de kernel (door te bewerken /etc/default/grub)

  • Plaats de lijn

    session required pam_loginuid.so

in alle PAM-configuratiebestanden die relevant zijn voor inloggen (/etc/pam.d/{login,kdm,sshd}), maar niet in de bestanden die relevant zijn voor su of sudo. Dit zal toestaan auditd om de bellende gebruiker te krijgen uid correct tijdens het bellen sudo of su.

  • Start nu uw systeem opnieuw.

  • Laten we inloggen en enkele commando's uitvoeren:

    $ id -u
    1000
    $ sudo ls /
    bin boot data dev etc home initrd.img initrd.img.old lib lib32 lib64 lost + found media mnt opt ​​proc root run sbin scratch selinux srv sys tmp usr var vmlinuz vmlinuz.old
    $ sudo su -
    # ls / etc
    [...]

Dit levert zoiets op /var/log/audit/auditd.log:

----
time->Mon Feb  4 09:57:06 2013
type=PATH msg=audit(1359968226.239:576): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968226.239:576): item=0 name="/bin/ls" inode=2117 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968226.239:576):  cwd="/home/user"
type=EXECVE msg=audit(1359968226.239:576): argc=2 a0="ls" a1="/"
type=SYSCALL msg=audit(1359968226.239:576): arch=c000003e syscall=59 success=yes exit=0 a0=10cfc48 a1=10d07c8 a2=10d5750 a3=7fff2eb2d1f0 items=2 ppid=26569 pid=26570 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ls" exe="/bin/ls" key=(null)
----
time->Mon Feb  4 09:57:06 2013
type=PATH msg=audit(1359968226.231:575): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968226.231:575): item=0 name="/usr/bin/sudo" inode=530900 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968226.231:575):  cwd="/home/user"
type=BPRM_FCAPS msg=audit(1359968226.231:575): fver=0 fp=0000000000000000 fi=0000000000000000 fe=0 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=ffffffffffffffff new_pi=0000000000000000 new_pe=ffffffffffffffff
type=EXECVE msg=audit(1359968226.231:575): argc=3 a0="sudo" a1="ls" a2="/"
type=SYSCALL msg=audit(1359968226.231:575): arch=c000003e syscall=59 success=yes exit=0 a0=7fff327ecab0 a1=7fd330e1b958 a2=17cc8d0 a3=7fff327ec670 items=2 ppid=3933 pid=26569 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="sudo" exe="/usr/bin/sudo" key=(null)
----
time->Mon Feb  4 09:57:09 2013
type=PATH msg=audit(1359968229.523:578): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968229.523:578): item=0 name="/bin/su" inode=44 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968229.523:578):  cwd="/home/user"
type=EXECVE msg=audit(1359968229.523:578): argc=2 a0="su" a1="-"
type=SYSCALL msg=audit(1359968229.523:578): arch=c000003e syscall=59 success=yes exit=0 a0=1ceec48 a1=1cef7c8 a2=1cf4750 a3=7fff083bd920 items=2 ppid=26611 pid=26612 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="su" exe="/bin/su" key=(null)
----
time->Mon Feb  4 09:57:09 2013
type=PATH msg=audit(1359968229.519:577): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968229.519:577): item=0 name="/usr/bin/sudo" inode=530900 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968229.519:577):  cwd="/home/user"
type=BPRM_FCAPS msg=audit(1359968229.519:577): fver=0 fp=0000000000000000 fi=0000000000000000 fe=0 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=ffffffffffffffff new_pi=0000000000000000 new_pe=ffffffffffffffff
type=EXECVE msg=audit(1359968229.519:577): argc=3 a0="sudo" a1="su" a2="-"
type=SYSCALL msg=audit(1359968229.519:577): arch=c000003e syscall=59 success=yes exit=0 a0=7fff327ecab0 a1=7fd330e1b958 a2=17cc8d0 a3=7fff327ec670 items=2 ppid=3933 pid=26611 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="sudo" exe="/usr/bin/sudo" key=(null)
----
time->Mon Feb  4 09:57:09 2013
type=PATH msg=audit(1359968229.543:585): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968229.543:585): item=0 name="/bin/bash" inode=6941 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968229.543:585):  cwd="/root"
type=EXECVE msg=audit(1359968229.543:585): argc=1 a0="-su"
type=SYSCALL msg=audit(1359968229.543:585): arch=c000003e syscall=59 success=yes exit=0 a0=13695a0 a1=7fffce08a3e0 a2=135a030 a3=7fffce08c200 items=2 ppid=26612 pid=26622 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="bash" exe="/bin/bash" key=(null)
----
time->Mon Feb  4 09:57:11 2013
type=PATH msg=audit(1359968231.663:594): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968231.663:594): item=0 name="/bin/ls" inode=2117 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968231.663:594):  cwd="/root"
type=EXECVE msg=audit(1359968231.663:594): argc=3 a0="ls" a1="--color=auto" a2="/etc"
type=SYSCALL msg=audit(1359968231.663:594): arch=c000003e syscall=59 success=yes exit=0 a0=7fff8c709950 a1=7f91a12149d8 a2=1194c50 a3=7fff8c709510 items=2 ppid=26622 pid=26661 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ls" exe="/bin/ls" key=(null)

De auid kolom bevat de bellende gebruiker uid, waarmee u kunt filteren voor opdrachten die door deze gebruiker worden uitgevoerd

 ausearch -ua 1000

Hiermee worden zelfs de opdrachten weergegeven die de gebruiker als root heeft uitgevoerd.

bronnen:


72
2018-02-04 09:16



+50 Dit antwoord lijkt het meest uitgebreid, hoewel ik een beetje teleurgesteld ben dat het nogal gecompliceerd is verlopen. Bedankt voor je bijdrage. - grassroot
Wees gewaarschuwd dat deze veranderingen iemands logvolume aanzienlijk kunnen vergroten in /var/log/audit/audit.log. Mijn logvolume naar dit bestand is meer dan verdubbeld na het toevoegen van de twoexecve-regels aan audit.rules - JDS


Onthoud dat sudo zelf alle sudo-opdrachten in de syslog registreert, dus alle priv'd-gebruikers moeten worden opgeleid om niet alleen sudo te doen om een ​​rootshell te krijgen, maar om:

sudo command p1 p2 ... pn

Het probleem met deze of enige benadering waar ik aan heb gedacht, is dat als het root gebruiker, het is vrij moeilijk om te voorkomen dat een gebruiker een specifiek type logging ontwijkt. Dus alles wat je probeert zal <100% zijn, het spijt me te moeten zeggen.

Onderwijs, documentatie, handhaving en vooral vertrouwen is wat nodig is.


8
2018-01-20 06:46



Ik begrijp dat niets perfect zal zijn, maar we zullen nooit iedereen zover krijgen dat het werkt zoals jij beschrijft. Dit zijn sysadmins waar we het over hebben;) - Soviero
Niet waar ... tenminste twee zeer grote bedrijven met wie ik persoonlijk heb gewerkt, bestaande uit een groot aantal systeembeheerders, hebben dit beleid al op hun plaats! Nogmaals, met educatie en handhaving werkt het. - mdpc
mdpc is 100% correct. Dit is precies waar het sudo-commando voor is. Ik zit in een winkel van tien sysadmins met honderden hosts, en we gebruiken individuele sudo-opdrachten voor alles - er is een specifiek beleid dat verbiedt root te worden via su -. Het is de enige redelijke manier om ervoor te zorgen dat de beheeractiviteiten naar behoren worden gecontroleerd. - Jeff Albert
-1 Onderwijs zal het nooit doen. We leven in een uitbestede wereld waar u slechts een van de vele klanten van uw sysadmins bent. - grassroot


Ik kreeg ooit te maken met hetzelfde probleem en moest een snelle en vuile oplossing bedenken - elke sudo-gebruiker heeft zijn eigen geschiedenisbestand zodra ze het commando uitvoeren sudo -i

In /root/.bashrc Ik heb de volgende regel toegevoegd -

 export HISTFILE=/root/.bash_history-$SUDO_USER
 export HISTTIMEFORMAT="%F %T "

Dus elke gebruiker die sudos naar root heeft een geschiedenisbestand .bash_history-gebruikersnaam.

Een andere methode -

Voeg de volgende code toe aan /root/.bashrc en het zal de gebruikersnaam, sudo-gebruiker en de opdracht toevoegen aan het logbestand, waar ooit het notificatieniveau is ingesteld, meest waarschijnlijk / var / log / messages.

function log2syslog
{
   declare COMMAND
   COMMAND=$(fc -ln -0)
   logger -p local1.notice -t bash -i -- "${USER}:${SUDO_USER}:${COMMAND}"
}
trap log2syslog DEBUG

Dank aan - http://backdrift.org/logging-bash-history-to-syslog-using-traps


5
2018-01-31 20:03



Leuke benadering, hoewel niet helemaal wat werd gevraagd. Ik zou graag een auditd of soortgelijke oplossing zien. - grassroot
ok ik heb het bijgewerkt om op val methode te vertrouwen. - Daniel t.
En voor legitieme gebruikers werkt dit. Maar als dat account gebarsten was, kon de cracker de bash-geschiedenis snel uitschakelen door te draaien /bin/sh, unset HISTFILE of /bin/bash --norc. - Stefan Lasiewski


Een aantal vestigingen verbiedt het gebruik van auditd feitelijk, omdat het om een ​​bron gaat en mogelijk tot een kans voor denial-of-service-aanvallen leidt.

Een oplossing is om de nieuwste Korn-shell te configureren (ksh-93, zie http://kornshell.com/ voor details) om alle opdrachten die als root worden uitgevoerd te loggen naar een externe syslog-server en vervolgens door beleid te eisen dat sysadmins zich aanmelden in persoonlijke accounts, behalve in noodsituaties, en de verbeterde Korn-shell uitvoeren via sudo. Onderzoek van de logboeken kan detecteren wanneer een admin een nieuwe shell uit de goedgekeurde shell lanceert om hun tracks te dekken en de SA kan vervolgens worden opgeleid als dat nodig is.


3
2018-02-06 19:28





Sinds versie 2.0.0 snoopy kan een willekeurige omgevingsvariabele registreren.

Recente bijdrage wees er echter op dat het loggen van eigenaar van tty een redelijk effectief en elegant antwoord is op de vraag: "Wie heeft die opdracht als root uitgevoerd?".

Openbaarmaking: ik ben snoopy beheerder.


3
2017-11-05 23:20



Geef instructies voor het instellen volgens de vereisten van OP, in plaats van een eenvoudige link. Bedankt. - Andrea Lazzarotto
-1. Dit is gewoon een plug voor snoopy. U hebt de openbaarmaking gevolgd, maar u hebt de vraag in uw bericht nog steeds niet beantwoord; je hebt net gekoppeld aan je project. - Duncan X Simpson


Sudo heeft iets genaamd sudoreplay wanneer ingeschakelde sessies worden vastgelegd en later opnieuw kunnen worden afgespeeld, werkt het vergelijkbaar met de script commando dat een typoscript van terminalsessie maakt dat later opnieuw kan worden afgespeeld met de scriptreplay commando.


3
2018-04-21 21:09





Niet dat er tot nu toe iets mis is met de andere antwoorden, maar als je dat beslist sudois aan het loggen via syslog is bevredigend, mag ik een rimpel voorstellen: log het via het netwerk in bij een externe audit-host.

Dat krijgt het probleem van "nu ik root ben geworden, kan ik elk spoor van mijn misdrijf verwijderen uit de logs". U kunt nu root zijn op het lokale vak, maar u kunt dat logpacket niet terugroepen van het netwerk en u hebt (vermoedelijk) geen rootprivileges op de externe audit-host.

Ik doe dit met een aantal van de netwerken die ik jarenlang beheer en heeft nog twee andere signaalvoordelen:

Ten eerste is er één plaats op het netwerk om alle syslogs te controleren, wat een veel eenvoudiger correlatie van incidenten mogelijk maakt, en zo is er een one-stop-shop voor onderzoeken zoals "Wanneer junoklaagde die NFS-server hera reageerde niet, klaagde iemand anders hetzelfde over hetzelfde? Als, hera is waarschijnlijk het probleem, laten we kijken wat ze heeft vastgelegd; als niet, junoDe netwerkverbinding is verdacht, laten we eens kijken wat nog meer juno op dat moment ingelogd. ".

Ten tweede wordt het loggen van syslog-logboeken eenvoudiger: u bewaart geen kopieën van logboeken bij lokale hosts gedurende meer dan een paar dagen, maar u zorgt ervoor dat de auditserver enorme hoeveelheden schijfruimte heeft en bewaart alle syslogs al enkele jaren. En als u bijvoorbeeld wilt schrijven naar WORM-media voor bijvoorbeeld forensische auditdoeleinden, hoeft u slechts één WORM-station te kopen.


1
2018-02-04 09:27