Linux за българи: Форуми

Чудех се дали отново да използвам думата "лъже" като в предишната ми тема "Защо" за fdisk, тъй като отново става дума за подвеждаща информация, но в случая не става дума точно за грешна информация, а по-точно за липса на такава.
Ако някой от четящите темата не знае, командата last показва записки за влизалите в системата потребители (за повече информация - команда man last). Такива потребители могат да са не само реалните потребители в системата, с които се влиза директно през tty и pts (като локални потребители, през SSH, през FTP с реални потребители и т.н.), но и псевдо потребителите на разни услуги в системата от FTP с виртуални потребители, та до псевдо потребителите при reboot и halt.
Когато някой потребител влезе в системата, в лога на last (по подразбиране това е /var/log/wtmp) се записва името на потребителя, tty/pts, който е използвал, IP адрес/hostname, дата и час на влизане, а след като потребителят излезе се записват и дата и час на излизане.

Та... къде last мълчи? Оказва се, че last мълчи, когато потребителите влязат в системата без да използват tty/pts. Такива са случаите, когато потребителят влезе през SFTP клиент, rsync и SCP. Един често срещан сценарий на такова влизане е през "Shell link" опцията на mc.

Въпросът е, след като в тези случаи пак си имаме влизане на потребители, които пак могат да изпълняват команди (най-малкото през cron), защо last не регистрира тези влизания? Логичният отговор е "Защото last записва само влизанията през tty/pts.", но не намирам някъде в документацията на last да се споменава нещо подобно. Има ли някаква реална спънка в системата, която да пречи на last да записва тези влизания, или е само пропуск в реализацията и документацията на last?

Ха-ха то ставало въпрос за команда. Като видях темата помислих, че станало скандал и (радио) last.fm не го е отразило, което ме учуди, защото това е музикално радио и не се занимава със скандали. А то каква била работата.

Е какво сега притеснява те, че някой може да достъпи отдалечено системата, без да научиш за това? Е то има разни нетстати и разни други дето могат да подскажат за не регламентирани влизания.

Това го знае всеки зъл хакер - редовният номер е влизане в системата с ssh -T.

Проблемът не е в last - командата просто изписва каквото има в wtmp.

Е какво сега притеснява те, че някой може да достъпи отдалечено системата, без да научиш за това? Е то има разни нетстати и разни други дето могат да подскажат за не регламентирани влизания.

В изхода от netstat се вижда само текущата комуникация, а last показва и записки от предишни влизания (от създаването на /var/log/wtmp натам). Да, влизането може да се види в някой от другите логове (/var/log/secure, /var/log/auth.log, /var/log/messages или там, който лог се грижи да пази записките за това влизане), стига този, който е влизал, да не е махнал записа за това оттам.
Но точно откъм махането на тези записи е предимството на last. За разлика от другите логове, /var/log/wtmp не е в чист вид и е труден за редактиране. При другите логове е достатъчно потребителят да пусне едно скриптче във фонов режим, което след излизането на потребителя да махне записите за неговото влизане от съответния лог, да върне датата на файла към подходяща дата, след което скриптът да се самоизтрие, и случката може да остане незабелязана. При /var/log/wtmp, за да скрие влизането си, потребителят най-вероятно ще трябва направо да изтрие файла или да върне някой от backup-натите, а това е достатъчна индикация, че нещо се е случило.
Разбира се, към всяка услуга може да се върже някакво демонче, което да праща e-mail (или sms, или друга отдалечена индикация) при всяко успешно или неуспешно влизане в системата през дадената услуга, но не се ли оказва тогава last (и, въобще, /var/log/wtmp, а и lastb с неговия /var/log/btmp) безсмислен и излишен?

Проблемът не е в last - командата просто изписва каквото има в wtmp.

Да, въпросът е къде е недомислието, водещо до това обезсмисляне на last и придружаващите го логове? :)

Няма обезсмисляне, просто само определени програми пишат в wtmp - от сорта на getty-подобните, login и т.н. По същата причина спокойно можеш да отвориш listening socket и да го вържеш с bash, примерно ползвайки netcat за целта и пак няма да се логне.

Това е същото като с tcpwrappers - за някои услуги може да важи, за други може и да не важи.

Хмм... ясно. Т.е., излиза, че всяка програма поотделно се грижи да пише в wtmp, а не някаква глобална функция в системата, и така е много лесно да бъде избегнат записът. Язък - оказва се, че досега съм имал повече доверие на изхода от last, отколкото е било редно. Явно няма проблем в last (съответно wtmp), нито някакви спънки в системата, които да му пречат да работи коректно - просто работата му е съвсем друга.
Е, все пак си мисля, че има нужда от една такава глобална функция в системата, на която да можеш да имаш повече доверие, която да си работи "as it is" - без допълнителни ръчкания, които да повишат вероятността от пропуски. Но е друг въпрос как ще се реализира :)

Не съм запознат с темата, но ако разсъждавам, ми излежда от програмистка гледна точка по-трудно да се направи, така че всяка програма сама да логва.

Не може ли просто да има един PAM модул, който да се извиква при success да записва винаги в wtmp кой се логва.

В смисъл... изглежда логично...

Така, че Геит, не мога да се съглася с теб.

Ся ми се пикае и мързи а е и почти един. Утре ще видя как може да се пипне това...

Не мисля че е толкова лесно това да се направи, поради това че има доста начини човек да изпълнява команди на системата и някои от тях определено няма как да са "отговорни" спрямо подобен logging механизъм. Неща като auditd иначе са хубави, но създават обемни логове и в края на крайщата не ти казват кой кога се е логнал, просто кой кога е изпълнил нещо. В grsecurity по спомени имаше малко по-развита разновидност, която логваше и IP адреса на изпълнилия програмата. Това отваря друг проблем - кой ще чете и интерпретира огромните логове.

Като цяло иначе въпросът е по-скоро философски, отколкото технически. В момента не ми се развиват тези обаче :)

Не може ли просто да има един PAM модул, който да се извиква при success да записва винаги в wtmp кой се логва.

Ползването на PAM за автентициране на системни потребители също е пожелателно...това ни връща на същия проблем.

П.П стана някакво мазало, само да се поясня - примерно при public key автентикация в ssh, PAM обикновено не участва в сметките. Виждал съм преди време доста глупаво изпълнение - лошо администрирана машина, дебиан, потребителят www-data с home директория /var/www, шел /bin/bash (последното не е странно, много често apache потребителя има валиден шел, за да не се дънят system() и подобни в скриптовете), home директорията с права за запис, лошият си създал ~/.ssh/authorized_keys през някаква дупка в PHP приложение и си се логва като пич и прави пакости..

П.П стана някакво мазало, само да се поясня - примерно при public key автентикация в ssh, PAM обикновено не участва в сметките.

Аз си имам малка теория,

Трябва да се казва PAAM. Plugable Auth. & Authorization Module.

Защото ключовете са метод за автентикация, а не за оторизация.

sshd ако имплементира механизъма за работа с SSH ключове, тогава няма проблем да разбере дали човека може да се логне.

НО

Трябва да се допита до PAM за да разбере дали потребителя е оторизиран за това - например ако има включен pam_tally, дали потребителя е оторизиран да се логне след 5 грешни опита...

Това, че PAM не се използва в работата с ключове според мен е добре, защото така OpenSSH  може да си работи прекрасно и на системи без PAM.

Та на въпроса със SFTP-то...

Аз мисля, че Нетър сам си отговаря в поста:

Та... къде last мълчи? Оказва се, че last мълчи, когато потребителите влязат в системата без да използват tty/pts. Такива са случаите, когато потребителят влезе през SFTP клиент, rsync и SCP. Един често срещан сценарий на такова влизане е през "Shell link" опцията на mc.

От манюала:

"The wtmp file records all logins and logouts.  Its format is exactly like utmp except  that  a  null
       username indicates a logout on the associated terminal.  Furthermore, the terminal name ~ with user‐
       name shutdown or reboot indicates a system shutdown or reboot and the pair  of  terminal  names  |/}
       logs  the old/new system time when date(1) changes it. wtmp is maintained by login(1), init(8), and
       some versions of getty(8) (e.g., mingetty(8) or agetty(8)).  None  of  these  programs  creates  the
       file, so if it is removed, record-keeping is turned off.
"

Та и Гейт е прав де... обаче:

Късно е и малко залупих, SSH, ако иска да е от добрите ще използва PAM... само трябва да го излъжем да логва.


Така

В момента имам следния файл на Fedora 18:

[root@ivan-laptop pam.d]# ll /etc/pam.d/sshd
-rw-r--r--. 1 root root 676 17 фев  1,49 /etc/pam.d/sshd
[root@ivan-laptop pam.d]# cat /etc/pam.d/sshd
#%PAM-1.0
auth       required     pam_sepermit.so
auth       substack     password-auth
auth       include      postlogin
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    include      password-auth
session    include      postlogin

Ако направя следното:

[root@ivan-laptop pam.d]# sftp testuser@localhost
testuser@localhost's password:
Connected to localhost.
sftp>

Тогава last мълчи а Neter е притеснен.

Обаче,, бивайки офицер от запаса правя следното:

[root@ivan-laptop pam.d]# cat /etc/pam.d/sshd
#%PAM-1.0
auth       required     pam_sepermit.so
auth       substack     password-auth
auth       include      postlogin
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    include      password-auth
session    include      postlogin
session required  pam_lastlog.so


Сега правя пак:
[root@ivan-laptop pam.d]# sftp testuser@localhost
testuser@localhost's password:
Connected to localhost.
sftp>


И резултата е:

testuser ssh          localhost        Sun Feb 17 01:50   still logged in
testuser ssh          localhost        Sun Feb 17 01:49 - 01:49  (00:00)


Мога да ви кажа че това си е асъл sftp защото шела ми е /sbin/nologin.

Трикътлика е в модула pam_lastlog, който според документацията:

pam_lastlog is a PAM module to display a line of information about the last login of the user. In addition, the module maintains the /var/log/lastlog file.

И даже още по якото:

       nowtmp
           Don´t update the wtmp entry.

Да бе да :)

Така, че Гейт лошите винаги могат да намерят нещо да базикнат, ама и ние не сме много тъпи :) Дето вика един скроро..

Па тея си мислели че ние доматите с колците ги ядем :D