Zaloguj wszystkie polecenia uruchomione przez administratorów na serwerach produkcyjnych

Zasadą firmy jest, aby administratorzy logowali się na serwery za pomocą osobistej nazwy użytkownika, a następnie biegali, sudo -iaby zostać rootem. Po uruchomieniu sudo -isudo utworzy zmienną środowiskową o nazwie SUDO_USER, która zawiera oryginalną nazwę użytkownika.

Czy istnieje sposób na zarejestrowanie WSZYSTKICH poleceń w syslog przy użyciu czegoś podobnego do następującej składni:

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

Przykładowy wpis to:

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

Oczywiście nie musi to być dokładnie powyższa składnia, musi ona zawierać minimum rzeczywistego użytkownika (np. Root), użytkownika sudo (np. Ksoviero) i pełne polecenie, które zostało uruchomione (np. Yum zainstaluj random-pkg).

Próbowałem już snoopy, ale nie zawierała SUDO_USERzmiennej.

Aktualizacja : jeszcze 2 rzeczy, które pojawiły się w komentarzach i dalszych pytaniach:

• Korzystanie z auditdtej metody znacznie zwiększy objętość dziennika, zwłaszcza jeśli system jest intensywnie używany za pomocą wiersza polecenia. Dostosuj zasady przechowywania dzienników.
• Auditddzienniki na hoście, na którym są tworzone, są tak samo bezpieczne, jak inne pliki w tym samym pudełku. Prześlij swoje dzienniki do zdalnego serwera zbierania dzienników, takiego jak ELK lub Graylog, aby zachować ich integralność. Dodatkowo, dodając do powyższego punktu, pozwala on bardziej agresywnie usuwać stare dzienniki.

Jak zasugerował Michael Hampton, tutaj auditdjest właściwe narzędzie do pracy.

Przetestowałem to na instalacji Ubuntu 12.10, więc twój przebieg może się różnić w innych systemach.

• Zainstaluj auditd:

  apt-get install auditd

• Dodaj te 2 linie do /etc/audit/audit.rules:

  -a wyjście, zawsze -F arch = b64 -F euid = 0 -S wykonanie
  -a wyjście, zawsze -F arch = b32 -F euid = 0 -S wykonanie

Śledzą one wszystkie polecenia uruchamiane przez root ( euid=0). Dlaczego dwie zasady? Połączenie execvesystemowe musi być śledzone zarówno w kodzie 32-bitowym, jak i 64-bitowym.

• Aby pozbyć się auid=4294967295wiadomości w logach, dodaj audit=1do cmdline jądra (edytując /etc/default/grub)

• Umieść linię

  session required pam_loginuid.so

we wszystkich plikach konfiguracyjnych PAM, które są istotne dla login ( /etc/pam.d/{login,kdm,sshd}), ale nie w plikach, które są istotne dla sulub sudo. Umożliwi auditdto uidprawidłowe uzyskanie dzwoniącego użytkownika podczas połączenia sudolub su.

• Uruchom ponownie system teraz.

• Zaloguj się i uruchom kilka poleceń:

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

To da coś takiego /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)

auidKolumna zawiera użytkownik wywołującego uid, który pozwala filtrować poleceń uruchamianych przez użytkownika z

 ausearch -ua 1000

Spowoduje to nawet wyświetlenie poleceń uruchomionych przez użytkownika jako root.

Źródła:

• http://www.woitasen.com.ar/2011/11/auditing-user-actions-after-sudo/
• http://linux.die.net/man/8/pam_loginuid
• http://linux.die.net/man/8/auditd

Pamiętaj, że samo sudo rejestruje wszystkie polecenia sudo w syslog, więc wszyscy prywatni użytkownicy powinni być edukowani, aby nie tylko sudo uzyskiwać powłokę root, ale:

sudo command p1 p2 ... pn

Problemem z tym lub innym podejściem, o którym myślałem, jest to, że jako rootużytkownik dość trudno jest zapobiec unikaniu przez użytkownika określonego rodzaju rejestrowania. Dlatego wszystko, czego spróbujesz, będzie <100% Przykro mi to mówić.

Konieczna jest edukacja, dokumentacja, egzekwowanie prawa, a przede wszystkim zaufanie.

Kiedyś napotkałem ten sam problem i musiałem wymyślić szybkie i brudne rozwiązanie - każdy użytkownik sudo będzie miał swój własny plik historii po uruchomieniu polecenia sudo -i

W /root/.bashrcdodałem następujący wiersz -

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

Tak więc każdy użytkownik, który sudo rootować, będzie miał plik historii .bash_history-username.

Inna metoda -

Dodaj następujący kod, /root/.bashrca doda on nazwę użytkownika, sudo-user i polecenie do pliku dziennika, gdzie kiedykolwiek ustawiony jest poziom powiadomienia, najprawdopodobniej / 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

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

Wiele zakładów faktycznie zabrania korzystania z audytu, ponieważ wymaga on dużych zasobów i może prowadzić do ataków typu „odmowa usługi”.

Jednym z rozwiązań jest skonfigurowanie najnowszej powłoki Korna (ksh-93, szczegółowe informacje na stronie http://kornshell.com/ ), aby rejestrować wszystkie polecenia wykonywane jako root na zdalnym serwerze syslog, a następnie wymagać tego zgodnie z zasadami, z wyjątkiem sytuacji awaryjnych sytuacje, administratorzy sysadmin logują się na konta osobiste i uruchamiają ulepszoną powłokę Korna przez sudo. Badanie dzienników może wykryć, kiedy administrator uruchamia inną powłokę z zatwierdzonej powłoki w celu pokrycia ich śladów, a następnie SA można edukować w razie potrzeby.

Sudo ma coś, co nazywa się sudoreplay, gdy włączone sesje są rejestrowane i można je odtworzyć później, działa podobnie jak scriptpolecenie, które tworzy maszynopis sesji terminalowej, którą później można odtworzyć za pomocą scriptreplaypolecenia.

Od wersji 2.0.0 snoopy może rejestrować dowolne zmienne środowiskowe.

Jednak niedawny wkład wskazał, że rejestrujący właściciel tty jest dość skuteczną i elegancką odpowiedzią na pytanie „Kto wykonał to polecenie jako root?”.

Ujawnienie: Jestem opiekunem snoopy.

Nie to, że do tej pory było coś nie tak z żadną inną odpowiedzią, ale jeśli uznasz, że sudologowanie za pośrednictwem syslogjest zadowalające, mogę zasugerować zmarszczkę: zaloguj się przez sieć do zdalnego hosta audytu.

To rozwiązuje problem: „Teraz zostałem rootem, mogę usunąć wszelkie ślady mojej nadużycia z logów”. Możesz być teraz rootem na lokalnej skrzynce, ale nie możesz wywołać tego pakietu dziennika z sieci i (prawdopodobnie) nie masz uprawnień roota na zdalnym hoście kontroli.

Robiłem to z niektórymi sieciami, którymi zarządzam od lat, i ma dwie inne zalety sygnalizacyjne:

Po pierwsze, jest jedno miejsce w sieci, aby sprawdzić wszystkie syslogs, co pozwala na znacznie łatwiejszą korelację incydentów, a więc jest to kompleksowe centrum badań takich jak „Kiedy junonarzekałem, że serwer NFS heranie odpowiada, czy ktoś jeszcze narzekał ta sama rzecz w tym samym czasie? Jeśli tak, herato może być problem, zobaczmy, co się zalogowała; jeśli nie, junopołączenie sieciowe jest bardziej podejrzane, zobaczmy, co jeszcze się junozalogowało w tym czasie. ".

Po drugie, rotacja dzienników syslog staje się łatwiejsza: nie przechowujesz kopii dzienników na lokalnych hostach przez więcej niż kilka dni, ale upewniasz się, że serwer audytu ma ogromne ilości miejsca na dysku i przechowujesz wszystkie syslogi przez kilka lat. Dodatkowo, jeśli powiedzmy, że chcesz zapisać je na nośniku WORM, np. W celu kontroli sądowej, musisz kupić tylko jeden napęd WORM.