Раскройте sudoer пользователя с полномочиями пользователя root, которые выполнили команду X?
С комбинацией dumpe2fs и debugfs, которые включены в e2fsprogs пакет вперед fsck.ext*.
Необходимо использовать вывод команды как аргумент следующего.
Эти инструменты автоматически обнаруживают размер блока файловой системы, таким образом, это последовательно и более безопасно, чем прямой badblocks вызов.
Печатает зарегистрированные сбойные блоки файловой системы:
# dumpe2fs -b DEVNAME
Печатает inodes, которые используют данный черный список:
# debugfs -R "icheck BLOCK ..." DEVNAME
Печатает пути к данному списку inode:
# debugfs -R "ncheck INODE ..." DEVNAME
debugfs имеет также интерактивную оболочку и -f cmd_file опция, но они не очень мощны или полезны для этого случая.
-R опция позволяет более автоматизированные сценарии как это:
#!/bin/sh
# Finds files affected by bad blocks on ext* filesystems.
# Valid only for ext* filesystems with bad blocks registered with
# fsck -c [-c] [-k] or -l|-L options.
# Can be extremely slow on damaged storage (not just a corrupt filesystem).
DEVNAME="$1"
[ -b "$DEVNAME" ] || exit 1
BADBLOCKS="$(dumpe2fs -b "$DEVNAME" | tr '\n' ' ')"
[ -n "$BADBLOCKS" ] || exit 0
INODES="$(debugfs -R "icheck $BADBLOCKS" "$DEVNAME" | awk -F'\t' '
NR > 1 { bad_inodes[$2]++; }
END {
for (inode in bad_inodes) {
if (inode == "<block not found>") {
printf("%d unallocated bad blocks\n", bad_inodes[inode]) > "/dev/stderr";
continue;
}
printf inode OFS;
}
}
')"
[ -n "$INODES" ] || exit 0
debugfs -R "ncheck -c $INODES" "$DEVNAME"
Если Вы смотрите через /var/log/audit/audit.log файл необходимо смочь выстроить в линию время/дату когда ssh файл был изменен с тем, когда один из 3 из пользователей с sudoers полномочиями вошел в систему.
audit.log файл содержит строки как это:
type=USER_START msg=audit(1374006520.730:480): user pid=28303 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session open acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/7 res=success)'
type=CRED_ACQ msg=audit(1374006535.446:488): user pid=28352 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: setcred acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/7 res=success)'
type=USER_START msg=audit(1374006535.448:489): user pid=28352 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session open acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/7 res=success)'
Можно отследить в обратном порядке AUID (Эмоциональный идентификатор пользователя - иначе. пользователь, который работал sudo команда).
Таким образом, AUID 500 является этим парнем в моей системе:
$ grep 500 /etc/passwd
sam:x:500:500:Sam M.:/home/sam:/bin/bash
Теперь audit.log может быть захвачен, но намного легче использовать инструмент ausearch просканировать через него. С одной стороны, это распечатает метку времени контрольного журнала в более человекочитаемой форме:
$ ausearch -x /usr/bin/sudo
...
time->Thu Jul 18 14:41:48 2013
type=CRED_ACQ msg=audit(1374172908.936:45): user pid=21252 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: setcred acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/5 res=success)'
----
time->Thu Jul 18 14:41:48 2013
type=USER_START msg=audit(1374172908.937:46): user pid=21252 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session open acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/5 res=success)'
Здесь я перерываю файл журнала, ища соответствия, которые содержат исполняемый файл sudo, (-x /usr/bin/sudo).
Я собираюсь записать ответ с RHEL в памяти, но просто знать, что, если Вы находитесь на SuSE или находящемся в Debian дистрибутиве, там будут аналогами для того, что я описываю.
Прежде всего, если Вы просто хотите проверить, что это было системное обновление и не кто-то пробующий к руткиту машина, можно "проверить" openssh-clients пакет как так:
[root@hypervisor scsd]# rpm -V openssh-clients
[root@hypervisor scsd]#
[root@hypervisor scsd]# rpm -V openssh-server
S.5....T. c /etc/pam.d/sshd
S.5....T. c /etc/ssh/sshd_config
[root@hypervisor scsd]#
Я сделал openssh-server также, таким образом, Вы видите то, на что похоже, когда что-то изменилось. Важная часть "5", который говорит нам, что md5sum файла отличается, чем, что существует в базе данных RPM. Если это проверяет его происходил, вероятно, из-за системного обновления.
Если они использовали конфетку (очень вероятно), будет запись /var/log/yum.log для того обновляемого об/мин. Это полезно для получения определенного времени, с которым обновление произошло для более позднего обзора yum history.
Если они использовали rpm непосредственно можно или сделать некоторых queryformat волшебство или rpm -q openssh-clients --last для получения даты, это произошло (хотя это кажется, что Вы уже знаете что бит информации),
Существует a yum подкоманду называют history это записывает auid/loginuid пользователя вызова:
[root@hypervisor scsd]# yum history
Loaded plugins: product-id, refresh-packagekit, rhnplugin, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
This system is receiving updates from RHN Classic or RHN Satellite.
ID | Login user | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
54 | <jadavis6> | 2013-07-15 09:03 | Install | 2
53 | <jadavis6> | 2013-07-09 17:25 | Update | 23
52 | <jadavis6> | 2013-06-24 10:10 | Install | 3 <
51 | <jadavis6> | 2013-06-14 22:33 | Install | 1 >
50 | <jadavis6> | 2013-06-14 07:47 | E, I, U | 90
49 | root <root> | 2013-06-14 00:58 | Update | 1
48 | <jadavis6> | 2013-06-03 08:28 | Install | 3
47 | <jadavis6> | 2013-05-28 11:57 | Install | 3 <
46 | <jadavis6> | 2013-05-20 18:25 | Install | 1 >
45 | <jadavis6> | 2013-05-20 12:00 | Install | 1
44 | <jadavis6> | 2013-05-19 15:29 | Install | 6
43 | <jadavis6> | 2013-05-18 20:16 | Install | 3
42 | <jadavis6> | 2013-05-16 16:21 | Install | 2 <
41 | <jadavis6> | 2013-05-16 12:48 | Install | 1 >
40 | <jadavis6> | 2013-05-10 09:28 | Install | 1
39 | <jadavis6> | 2013-05-10 09:28 | Install | 1
38 | <jadavis6> | 2013-04-29 19:45 | Install | 2 <
37 | <jadavis6> | 2013-04-29 18:51 | Install | 8 >
36 | <jadavis6> | 2013-04-29 18:35 | Update | 11
35 | <jadavis6> | 2013-04-27 15:44 | E, I, O, U | 429 EE
history list
[root@hypervisor scsd]#
loginuid unforgable, потому что, поскольку дети init отделены, они запускают с loginuid-1 (отрицательный). Когда Вы регистрируете на пути tty или sshd pam_loginuid (существуют другие модули, которые также делают это), устанавливает его на UID аутентифицируемого пользователя. После того, как набор к чему-то другому, чем -1 даже корень не может изменить это значение (только в более новых ядрах, хотя), так как это - non-functional/accounting-only и должно учесть, что взломщик, возможно, получил корень. Все дети наследовали loginuid родителя, итак даже при том, что sudo порождает программу с EUID нуля (или какой бы ни пользователь), Вы все еще собираетесь иметь тот же loginuid.
Можно протестировать это, просто делая долю sudo's и делая a cat /proc/self/loginuid каждый раз, когда это должно пользователь, Вы первоначально вошли в систему как, неважно, сколько su или sudo вызовы Вы сделали с тех пор. Это то, как yum history там знает jadavis6 сделал yum update даже при том, что я сделал их всех как пользователь root.
Если существует некоторая неоднозначность между двумя вкусными транзакциями, можно сделать a yum history info <transID> как то, если я хотел знать больше о той последней транзакции:
[root@hypervisor scsd]# yum history info 35
Loaded plugins: product-id, refresh-packagekit, rhnplugin, security,
: subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
This system is receiving updates from RHN Classic or RHN Satellite.
Transaction ID : 35
Begin time : Sat Apr 27 15:44:57 2013
Begin rpmdb : 959:3d300ae2e8dc239f9f972306ba2406bd22ba29bc
End time : 15:50:39 2013 (5 minutes)
End rpmdb : 972:381cb76592ea2f779ee4521a4e7221196520486a
User : <jadavis6>
Return-Code : Success
Command Line : update -y
Transaction performed with:
Updated rpm-4.8.0-27.el6.x86_64 @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
Updated subscription-manager-0.99.19.4-1.el6_3.x86_64 @rhel-x86_64-server-6
Updated yum-3.2.29-30.el6.noarch @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
Installed yum-metadata-parser-1.1.2-16.el6.x86_64 @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
Packages Altered:
Updated NetworkManager-glib-1:0.8.1-34.el6_3.x86_64 @rhel-x86_64-server-6
Update 1:0.8.1-43.el6.x86_64 @rhel-x86_64-server-6
Updated PackageKit-0.5.8-20.el6.x86_64 @rhel-x86_64-server-6
Update 0.5.8-21.el6.x86_64 @rhel-x86_64-server-6
Updated PackageKit-device-rebind-0.5.8-20.el6.x86_64 @rhel-x86_64-server-6
[...snip...]
Updated yum-3.2.29-30.el6.noarch @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
Update 3.2.29-40.el6.noarch @rhel-x86_64-server-6
Updated yum-rhn-plugin-0.9.1-40.el6.noarch @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
Update 0.9.1-43.el6.noarch @rhel-x86_64-server-6
Scriptlet output:
1 warning: /etc/shadow created as /etc/shadow.rpmnew
2 No input from event server.
3 warning: %postun(wdaemon-0.17-2.el6.x86_64) scriptlet failed, exit status 1
history info
Я усеченный это, потому что это похоже на этого, было довольно долгое системное обновление.
AFAIK там не является никаким способом проследить его, если они обновили через rpm непосредственно за пределами конфигурирования auditd наблюдать изменения в файлы базы данных RPM. Выполнение так позволило бы Вам сделать ausearch позволит Вам видеть список PID, который делал изменения и loginuid связанными (который будет отображен как auid).
Если бы они непосредственно изменили его за пределами об/мин, то необходимо было бы наблюдать каждый из файлов, которые Вы хотели контролировать для изменений, прежде чем изменение было внесено. После факта Вы не можете сделать многого, но Вы могли бы рассмотреть выполнение чего-то с auditd для контроля файлов, Вы чувствуете, цели руткита. Выполнение слишком много может сорвать систему. Также стоит упомянуть, что необходимо поставить эти журналы, вне сервера куда-нибудь для предотвращения злонамеренного вмешательства.
Надежда, которая помогает.
Править:
Одна вещь отметить, похоже, что корень может изменить loginuid, если это имеет CAP_SYS_AUDITCONTROL (не требуемый, если loginuid в настоящее время -1) но необходимо смочь удалить ту возможность из набора ограничения системы, который потребовал бы, чтобы взломщик перезагрузил систему для получения той возможности, которая является шумным как операцией ада, которая оставляет auditable события повсеместно, таким образом, они вряд ли сделают это.
Вы проверили syslog? Согласно man sudo: sudo может зарегистрировать и успешные и неудачные попытки (а также ошибки) к системному журналу (3), файл журнала или оба. По умолчанию sudo зарегистрируется с помощью системного журнала (3), но это изменяемо в, настраивают время или через sudoers файл.
Я думал бы, что, если они намеренно не удалили файл журнала, необходимо смочь получить информацию там. Для сужения периода времени, можно проверить измененную отметку даты на SSH util.