8(495)909-90-01
8(964)644-46-00
pro@sio.su
Главная
Системы видеонаблюдения
Охранная сигнализация
Пожарная сигнализация
Система пожаротушения
Система контроля удаленного доступа
Оповещение и эвакуация
Контроль периметра
Система домофонии
Парковочные системы
Проектирование слаботочных сетей
Аварийный
контроль
            
Раздел: Документация

0 ... 50 51 52 53 54 55 56 ... 125

В системе UNIX программа регистрации пользователя определяет время его последнего входа в систему с помощью файла last log. В большинстве версий UNIX эта информация выводится при входе в систему. В некоторых версиях одновременно с этим сообщаются также сведения об успешных и неудачных попытках входа в систему. Такая информация должна насторожить вас. Так, если определенной учетной записью кроме вас никто не имеет права пользоваться, а вы замечаете, что предыдущий вход в систему произошел в выходные, когда вас точно не было на работе, стоит просмотреть другие log-файлы, чтобы определить, применял ли вашу учетную запись посторонний!

Файл /var/adm/sulog

Команда su позволяет получать права другого пользователя. После входа в систему под одним именем, пользователь может при помощи этой команды зарегистрироваться в ней под другим именем и паролем. Использование команды su регистрируется в файле /var/adm/sulog. Для тех же целей служит команда sudo, но при этом не нужен пароль.

Применение этих команд бывает обоснованным. Администратору может временно понадобиться другое имя пользователя, например для доступа к определенному системному файлу. Но той же командой сумеет воспользоваться и хакер, которому удалось проникнуть в систему. В любом случае следует периодически просматривать данный файл, чтобы обнаружить возможное злоупотребление этими командами.

Файл /var/adm/aculog

Файл предназначен для регистрации пользователей, подключающихся к другим системам при помощи модема. В него также записываются действия команд UUCP, хотя в настоящее время UUCP уже почти не применяется и постепенно вытесняется новыми утилитами. В этом файле фиксируется имя пользователя, сделавшего звонок, набранный телефонный номер и был ли этот звонок успешным.

Модемный доступ лучше всего обеспечивать посредством защищенного компьютера, размещенного в демилитаризованной зоне или даже отключенного от сети. Не забывайте о том, что установка модемов на компьютерах в сети фактически означает, что вас не беспокоит проблема несанкционированного доступа к сети. А зачем тогда нужен межсетевой экран?

Файл /var/log/cron

Для автоматизации задач в UNIX предназначен демон сгоп. Он позволяет создавать командные файлы, которые могут запускаться в определенное время без вмешательства пользователя. Хотя большинство современных версий этого демона выполняют аудит с помощью утилиты syslog, существует и отдельный log-файл


/var/log/сгоп. Если хакеры получат доступ к файлу настроек демона сгоп, они сумеют запустить по расписанию задачу и с ее помощью войти в систему или добиться повышенных привилегий. Регулярно просматривайте файл настроек и log-файл сгоп. Или, что еще лучше, следите за его использованием, настроив соответствующим образом syslog.

Команда ps

Хотя команда ps и не работает с log-файлом, она бывает очень полезна во время исследования потенциальной бреши в системе защиты. Эта команда считывает таблицу процессов ядра UNIX и выводит информацию о запущенных процессах. Нарушителя, проникнувшего в систему и инициировавшего фоновый процесс, удается обнаружить при помощи этой команды. Поскольку сведения берутся не из log-файла, а из ядра, увеличивается вероятность того, что они будут точными. В зависимости от версии UNIX команда ps может выводить следующую информацию:

О идентификатор процесса; О имя пользователя;

О TTY (или используемый процессом терминал);

О время выполнения;

О выполняемую команду;

О процент используемого времени процессора;

О процент используемой памяти;

О время запуска процесса.

Когда шла речь о файле /etc/utmp, отмечалось, что искушенный хакер способен модифицировать его. Поэтому, сравнив содержимое этого файла с выводом команды ps, нетрудно обнаружить подозрительные процессы, заслуживающие дальнейшего анализа. Кроме того, так вам удастся обнаружить процессы, которые выполняются дольше, чем следует, или запущены пользователем, который не должен этого делать.

Система Windows NT

Операционная система Windows NT позволяет регистрировать большое число событий. Так же, как и в случае демона syslog в UNIX, прежде всего нужно определить регистрируемые события.

Но, в отличие от UNIX, для просмотра полученных сообщений вам понадобится всего одна утилита - Event Viewer. Правда, это касается лишь операционной системы. Некоторые приложения, например Internet Information Server, не только выполняют запись в Event Log (журнал событий), но и ведут собственные log-файлы. Программы других производителей также создают различные log-файлы.


Определение регистрируемых событий

Кроме утилиты Event Viewer, позволяющей просматривать регистрируемые события, существуют и другие утилиты, с помощью которых определяются регистрируемые события:

О User Manager (Менеджер пользователей) или User Manager for Domains при

работе в домене; О Windows NT Explorer;

О закладка Properties (Свойства) для принтера.

Рассмотрим вначале работу с User Manager. С помощью утилиты администратора, находящейся в папке Administrative Tools (Программы администрирования), задается политика аудита для сервера и управления учетными записями пользователей и доверительными связями в домене.

Выбор регистрируемых событий в User Manager

1.Выполните команды Start => Programs => Administrative Tools => User Manager (Пуск => Программы => Программы администрирования => Менеджер пользователей).

2.Выберите пункт Audit (Аудит) в меню Policies (Политика). Появится диалоговое окно Audit Policy (см. рис. 8.1).

3.Установите переключатель в положение Audit These Events (Регистрировать эти события).

4.Для каждого из событий, которые вы хотите регистрировать, отметьте один (или оба) из флажков Success (Успех) или Failure (Неудача).

5.Завершив выбор всех событий, щелкните мышью по кнопке ОК.

В диалоговом окне Audit Policy можно указать для каждого типа событий, какое их завершение записывать - удачное или неудачное. В первом случае событие, например вход пользователя в систему, фиксируется, если оно закончилось успехом. Во втором случае - наоборот. Так, если вы хотите знать только о случаях, когда пользователь пытался, но не смог войти в систему потому, что набрал неправильный пароль или по какой-то другой причине, установите для этого события флажок Failure. Допускается также одновременно записывать и удачные, и неудачные события.

----,-.-.---....

Отмена регистрации событий

На рис. 8.1 видно, что можно отменить регистрацию любых событий, установив переключатель в положение Do Not Audit (Выключить аудит). Чтобы отключить аудит на короткое время, воспользуйтесь этим переключателем. Тогда установленные вами настройки регистрации событий останутся без изменений. Если вы позже решите включить аудит, вам не потребуется вспоминать параметры регистрации, а будет достаточно всего лишь переставить переключатель в положение Audit These Events.



0 ... 50 51 52 53 54 55 56 ... 125