Comments 58
Как это защитит от ssh user@server /bin/bash -l?
+2
Опередили. Правда, я хотел предложить ssh user@host /bin/sh
0
Проверил. Логируется.
0
Это потому что
# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Mar 7 08:33 /bin/sh -> bash
В центоси есть к примеру /bin/dash, ну и всякие tcsh и прочие обычно в комплекте у некоторых
# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Mar 7 08:33 /bin/sh -> bash
В центоси есть к примеру /bin/dash, ну и всякие tcsh и прочие обычно в комплекте у некоторых
0
У меня на тестовой машине Debian Squeeze:
root@server:~# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jan 10 2013 /bin/sh -> dash
0
Вот не поверю, что ssh user@host «ls -l» тоже залогируется :)
0
Не логируется! Идей пока нет как решить, но чую, что если будут, то это будут большие костыли…
Есть идеи?
Есть идеи?
0
Как вариант есть возможность в ~/.ssh/authorized_keys сделать:
command="/bin/bash". Вижу сразу 2 нюанса:
1) Необходимо добавлять этот файл каждому пользователю
2) Авторизацию придётся запрещать по логину — только по ключу.
command="/bin/bash". Вижу сразу 2 нюанса:
1) Необходимо добавлять этот файл каждому пользователю
2) Авторизацию придётся запрещать по логину — только по ключу.
0
На уровне «положить файлик бла-бла-бла» — нет. Если серьёзно — смотреть в сторону:
а) сниффинга всего трафика, проходящего через псевдотерминалы
(более серьёзно)
б) систем аудита (SELinux/Apparmor/etc), которые будут записывать реально всё выполняемое.
Нужно понимать, что все эти screen, bash, history, etc — всего лишь условности интерфейсы, и никто не может принудить (то есть может — но это и есть SEL/AA) к их использованию.
Если пользователь может что-то запускать, значит у него тьюринг-полная система, значит, он может делать всякие странные вещи не оставляя следов. Если только сверху нет подобия *визора, фиксирующего всё на уровне ядра.
Вся описанная конструкция всего лишь паллиатив а-ля «запретить программу в window 9x». Решений много и все они обходятся из спортивного интереса.
а) сниффинга всего трафика, проходящего через псевдотерминалы
(более серьёзно)
б) систем аудита (SELinux/Apparmor/etc), которые будут записывать реально всё выполняемое.
Нужно понимать, что все эти screen, bash, history, etc — всего лишь условности интерфейсы, и никто не может принудить (то есть может — но это и есть SEL/AA) к их использованию.
Если пользователь может что-то запускать, значит у него тьюринг-полная система, значит, он может делать всякие странные вещи не оставляя следов. Если только сверху нет подобия *визора, фиксирующего всё на уровне ядра.
Вся описанная конструкция всего лишь паллиатив а-ля «запретить программу в window 9x». Решений много и все они обходятся из спортивного интереса.
0
Легко логируется враппером для sshd
а в хуке чтото вроде
ForceCommand /etc/ssh/rsh-hook.sh
а в хуке чтото вроде
if [[ ! -z ${SSH_ORIGINAL_COMMAND} ]]; then
. /etc/bash.bashrc
logger -p local6.debug -t "rem ${USER}" "${USER}: ${SSH_ORIGINAL_COMMAND}"
${SSH_ORIGINAL_COMMAND}
else
cat /etc/motd
${SHELL}
fi
+2
Если я правильно понимаю после аутентификации пользователь просто набирает /bin/bash -l. Проверил — логируется и это.
0
Нет, неправильно понимаете. ssh root@localhost -t /bin/bash -l и посмотрите логи.
Алсо, можно вообще /bin/bash -i, и тогда даже хистори не запишется.
Алсо, можно вообще /bin/bash -i, и тогда даже хистори не запишется.
0
И тот, и другой вариант логируется нормально.
Полагаю потому что bash при загрузке всё равно читает /etc/bash.bashrc.
А вот если эту возможность как-нибудь обойти… Надо подумать.
Полагаю потому что bash при загрузке всё равно читает /etc/bash.bashrc.
А вот если эту возможность как-нибудь обойти… Надо подумать.
0
Ну в лоб — написать малюсенькую библиотеку, которая перехватывает fopen и подсовывает нужные. А потом через LD_PRELOAD ее грузить…
Но думаю, это точно выходит за возможности потенциального нарушителя :)
Но думаю, это точно выходит за возможности потенциального нарушителя :)
0
Предполагается, что команду печают не на севрере. Я localhost сказал, чтобы на самой машине проверить можно будет.
0
Я проверил и удалённо, и локально — логируется. С другой машины ввёл:
Выхожу, смотрю логи:
ssh root@server -t /bin/bash -l
root@server's password:
root@server:~# this is a test message
bash: this: command not found
Выхожу, смотрю логи:
root@server:~# cat /var/log/screen/root@server-20130716-\ 9\:32\:04.log
root@server:~#
root@server:~# this is a test message
bash: this: command not found
root@server:~# ogout
0
--norc Do not read and execute the system wide initialization file /etc/bash.bashrc and the personal initialization file ~/.bashrc if the shell is interactive. This option is on by default if the shell is invoked as
sh.
Можно вот с этим ключиком и тогда ничего читать не будет, или можно указать при подключении явно, какой файл читать:
ssh root@localhost -t /bin/bash -i --rcfile <rc.file>
0
Да, вопрос наверное запоздалый. А почему бы просто не логгировать все происходящее с помощью conspy (http://ace-host.stuart.id.au/russell/files/conspy/) или аналогичного, который тупо грабит pts/*?
0
Для этого есть более подходящие решения
0
есть еще более подходящие.
0
Насколько мне известно auditd не логирует вывод информации на экран.
0
UFO just landed and posted this here
Согласен. Пожалуй security ради надо жёстко указать путь.
0
На логи можно попробовать натравить logrotate.
0
curl something | sh
Олсоу, логгирует ли оно всё происходящее в консольных редакторах вроде nano?
+1
screen -X log — отключает логгирование, и биндинг не нужен…
0
## Force SHELL close on exit - we don't want to allow users to escape logging outside screen
$KILL -SIGHUP $PPID
Здесь бы и просто 'exit' хватило.
0
Нет, не хватает. Тогда при выходе из screen (^d или просто exit) попадаем в bash без логирования. Поэтому и надо убить родительский процесс.
0
read answer
if [ "$answer" != "n" ]; then
screen -D -RR screen_name
exit
fi
(это на сервера прописываю, при заходе если не ответить «n», открывает прошлую сессию)
Работает как надо. Вопрос на linuxquestions
0
Спасибо за информацию. Считаю это не совсем нужным действием — отвечать нужно ли подключать, ведь для того, чтобы отключиться от screen и оставить работать процессы в фоне — надо проделать «телодвижения», соответственно зачем их проделывать, если потом отвечать «не подключать screen». А если просто выйти (^d или exit), то и screen убивается.
0
скроллинг назад в скрине не совпадает с «обычным» поведением.
Так же не совсем понятна изначальная постановка задачи. Иными словами — логгировать — ладно. Но зачем?
Если просто ради тайп-каста, то по-моему script более для этого приспособлен чем screen.
А если что-то типа шпиона — то наверное лучше вообще подключиться где-нибудь на уровне системы и наблюдать, что происходит во всевозможных ttyX.
Так же не совсем понятна изначальная постановка задачи. Иными словами — логгировать — ладно. Но зачем?
Если просто ради тайп-каста, то по-моему script более для этого приспособлен чем screen.
А если что-то типа шпиона — то наверное лучше вообще подключиться где-нибудь на уровне системы и наблюдать, что происходит во всевозможных ttyX.
0
Скроллинг назад под screen у меня абсолютно нормальный (Shift+PgUp), не считая возврата к предыдущему состоянию, когда минуты в caption внизу страницы меняют своё значение. А вот обычный скроллинг страниц, к примеру man bash — притормаживает. Другие претензии к screen в плане удобства, которые у меня были вначале — отсутствие «пикания» и автозавершения команд — исправлены и рецепт приведёт в статье.
Я старался не проводить в статье обзор методов аудита в Linux. Это статья для тех, кто как я, решит остановиться на этом методе из обзорной статьи про script, screen, sudo, auditd.
Вариант с подключением на уровне системы к ttyX думаю лучше, но я с ним не знаком и их не было в статье, на основании которой был выбран метод (см.выше).
Я старался не проводить в статье обзор методов аудита в Linux. Это статья для тех, кто как я, решит остановиться на этом методе из обзорной статьи про script, screen, sudo, auditd.
Вариант с подключением на уровне системы к ttyX думаю лучше, но я с ним не знаком и их не было в статье, на основании которой был выбран метод (см.выше).
0
del
0
Ну так закачиваем скрипт на сервер через sftp и выполняем там.
0
Думаю для таких вариантов нужно более серьёзные решения (auditd, к примеру), но там непросто читать лог-информацию.
К примеру на команду
В логе окажется:
К примеру на команду
“hostname audit-test.home.private”
В логе окажется:
type=SYSCALL msg=audit(1358306046.744:260): arch=c000003e syscall=170 success=yes exit=0 a0=2025010 a1=17 a2=7 a3=18 items=0 ppid=23922 pid=26742 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=16 comm="hostname" exe="/usr/bin/hostname" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="system-locale"
0
А что должен выводить кусок "%{kc}%{-b}%D" в caption always?
У меня на этом месте выводится какой-то юникодный мусор.
У меня на этом месте выводится какой-то юникодный мусор.
0
А вот, кстати, интересный способ вести лог команд в баше: askubuntu.com/questions/93566/how-to-log-all-bash-commands-by-all-users-on-a-server
0
Возможно, есть методы обойти screen и, соответственно, логирования при этой конфигурации. Хотелось бы услышать их и внести изменения
Ещё один метод обхода, не оставляющий следов:
Ctrl-A : log
Блокировка:
.screenrc
bind :
Пользователь теряет возможность выполнять команды screen и перенастраивать его.
0
Sign up to leave a comment.
Использование screen для логирования действий (аудита) пользователей в Linux