Михаил Флёнов - Linux глазами хакера

Пароли администраторов могут указываться в командной строке и при использовании программы 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-сайта.

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

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

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

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

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

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

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

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

logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= user=root

Параметр login(pam_unix)указывает на то, что хакер только пытается войти в систему. Если он уже проник, но неудачно использовал команду su, то в поле lognameбудет имя, под которым хакер находится в системе, и текст login(pam_unix)будет заменен на su(pam_unix).

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

logger -р kern.alert -t 'su(pam_unix)' "authentication failure ;

logname=robert uid=0 euid=0 tty=tty1 ruser= rhost= user=root "

В ответ на это в журнале будет создана примерно следующая запись:

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

logname=robert uid=0 euid=0 tty=tty1 ruser= rhost= user=root

Теперь представим, что хакер накидал строк, в которых поле lognameвсегда разное. Тогда выделить из них реальные практически невозможно.

Благо если при использовании директивы loggerхакер не будет использовать ключ -t, а укажет команду следующим образом:

logger -р kern.alert "authentication failure ;

logname-robert uid=0 euid=0 tty=tty1 ruser= rhost= user=root "

В этом случае в журнале будет строка:

Feb 12 17:31:37 FlenovM logger: authentication failure;

logname=robert uid=0 euid=0 tty=tty1 ruser= rhost= user=root

Как видите, перед сообщением об ошибке стоит ключевое слово logger, которое как раз и выдает подделку.

Даже если команда loggerне будет доступна хакеру, он может создать записи своей программой. Чтобы этого не произошло, журналы должны быть доступны на запись только администратору root.

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

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

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

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