Linux глазами хакера

/var/log/wtmp {
 monthly size = 100k
 create 0664 root utmp
 rotate 1
}

Теперь файл журнала будет меняться в двух случаях (по событию, которое наступит раньше):

□ ежемесячно, т.к. указан параметр monthly;

□ когда файл достигнет размера 100 Кбайт.

За счет смены журналов мы получаем как удобства, так и недостатки. Например, после проведения атаки хакер может уничтожить свои следы, даже если не имеет непосредственного доступа к файлам журнала. Достаточно только засыпать журнал мусорными сообщениями и превысить максимальный размер, чтобы система четыре раза произвела ротацию.

Пытаться защищать журнал, увеличивая его размер до бесконечности, бесполезно, потому что хакер не будет добавлять записи в log-файл вручную, а воспользуется простой программой на Perl или написанной прямо из командного интерпретатора (Shell). Такая программа чрезвычайно проста. Достаточно только в цикле выполнять команду:

logger -р kern.alert "Текст сообщения"

С помощью директивы logger можно записывать в журнал сообщения. Если организовать бесконечный цикл выполнения этой команды, то система сама уничтожит журнал.

Чтобы данные не исчезали бесследно, можно добавить команду, которая будет отправлять журнал на почтовый адрес администратора:

/var/log/wtmp {
 monthly
 size = 100k
 create 0664 root utmp
 postrotate
 # Команда отправки журнала имя.1
 endscript
 rotate 1
}

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

Если вы настраиваете сервис таким образом, убедитесь, что ваш почтовый ящик способен принять необходимое количество данных. Например, если вы установили максимальный размер файла в 10 Мбайт, а ваш почтовый ящик способен принять только 5 Мбайт, то вы никогда не получите этот файл, он будет удален почтовым сервером.

12.5.8. Пользовательские журналы

Все команды, которые выполняются пользователем, сохраняются в файле .bash_history (если используется интерпретатор команд /bin/bash), который находится в пользовательской домашней директории. Когда вы определили, под какой учетной записью в системе находился взломщик, его действия можно проследить по этому журналу.

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

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

Пользовательские журналы нужно регулярно проверять и очищать. Любой (да и вы сами) может ошибиться при написании какой-либо команды и указать свой пароль. Взломщик, проанализировав файл .bash_history, увидит пароли и сможет уничтожить ваш сервер.

Если вы в командной строке набирали директиву и указывали пароль администратора root, то не поленитесь удалить соответствующую запись из пользовательского журнала. Такая ошибка может вам обеспечить не одну бессонную ночь.

Пароли администраторов могут указываться в командной строке и при использовании программы mysql. Если вы выполнили команду /usr/bin/mysql -uroot -ppassword, то она полностью сохранится в журнале. Получив доступ к вашему журналу bash-команд, злоумышленник приобретает возможность использовать базу данных MySQL с правами root. В лучшем случае это будет только база данных, а в худшем (если пароль root на систему и на MySQL совпадают), — весь сервер будет под контролем взломщика.

Внимание!

Никогда не выполняйте в командной строке директивы, требующие указания пароля, а если сделали это, то удалите соответствующую запись из журнала bash. В случае с MySQL нужно было задать команду /usr/bin/mysql -uroot. В ответ на это сервер запросит пароль, который не сохранится в журнале, а запишется только введенная команда.

Если вы работаете с сервером базы данных MySQL, то в вашей домашней директории помимо файла .bash_history будет еще и .mysql_history. В этом файле хранятся все команды, которые выполнялись в программе конфигурирования mysql. Его также надо очищать, если при выполнении команды был указан какой-либо пароль. БД MySQL — это еще не вся ОС, но может послужить отправной точкой для дальнейшего взлома, к тому же сами базы данных могут содержать секретную информацию, например, пароли доступа к закрытым частям Web-сайта.

12.5.9. Обратите внимание

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

Если стали быстро увеличиваться журналы, значит, возросла активность и, возможно, началась атака отказа от обслуживания. Нужно срочно реагировать, иначе рост нагрузки на сервер или каналы связи может стать неуправляемым, и к определенному моменту сервер перестанет обрабатывать запросы пользователей. К тому же, если журналы заполнят весь диск, то система может выйти из строя. Убедитесь, что у вас достаточно места для хранения файлов журналов.

Компьютер не должен перегружаться без вашего ведома. Если это произошло, то проверьте журналы и выясните, по какой причине и когда это случилось. Момент последней загрузки Linux легко узнать с помощью команды uptime.

Следите за повторяющимися записями, особенно об авторизации. Если на каком-либо сервисе происходит много попыток входа с неверной идентификацией пользователя, это может говорить о том, что взломщик пытается подобрать пароль.

Если вы заметили что-то подозрительное (с учетом вышеперечисленного), то следует выяснить, откуда идет потенциальная угроза, а именно IP-адрес и расположение сети атакующего. Для предотвращения дальнейших действий со стороны взломщика можно изменить политику сетевого экрана, добавив запись, запрещающую любые подключения со стороны атакующего хоста.

При анализе журнала нужно быть очень бдительным и обращать внимание на каждую мелочь. Например, чтобы подобрать пароль, злоумышленник может использовать различные методы маскировки, в частности самостоятельно записывать в журнал подложные записи.

Если хакер будет подбирать пароль простым перебором, то вы легко увидите большое количество неудачных попыток войти под определенным пользователем, т.к. при этом в журнале /var/log/messages появляется следующая запись:

Feb 12 17:31:37 FlenovM login(pam_unix)[1238]: authentication failure;