как узнать, что на компе троян
Как обнаружить троян и узнать кто послал. Эта статья написана только в образовательных целях и рассчитана на аудиторию обыкновенных пользователей, без особых каких-то навыков. Материал, изложенный ниже дает только базовое понимание в данном аспекте. Сегодня речь пойдет о троянах и backdoor (далее только троян). Троян - может быть почтовым (отправляет на ящик хозяина (тот, кто послал троян) ваши пароли и другую информацию) или служить как система удаленного администрирования. Из-за неумелости троянописателей и скудности их воображения (я не имею в виду всех троянописателей, есть трояны действительно шедевры и их создателям - респект) все трояны однотипны и их легко определить в системе (то ли дело трояны использующие ACK-туннелирование). Троян всегда состоит из двух частей - клиентской и серверной. Именно сервер и закидывают жертве, чтобы потом с помощью клиента к нему подключиться и проворачивать нужные дела. Обычно трояны используют TCP или UDP соединения между своими клиентской и серверной частями. Любой файрволл между хозяином и жертвой, блокирующий входящий трафик, обычно предотвращает работу троянов. Некоторое время существовало ICMP-туннелирование, но у большинства современных файрволлов есть функция блокировки ICMP, что прикрыло еще одну дыру троянописателям. Я не собираюсь вдаваться в подробности, а лишь расскажу, как определить присутствие трояна в системе. Чтобы постоянно быть готовым принять подключение клиентской части, серверная часть трояна должна постоянно работать, т.е. даже после перезагрузки компьютера, для этого троян прописывает себя в автозагрузку. Основные места, куда может прописаться троян: 1)Реестр: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices 2)Файлы инициализации (win.ini и system.ini) а) В файле WIN.INI: [windows] load= тут_может_быть_троян run= и тут_может_быть_троян б) В файле SYSTEM.INI: в строках [386Enh] 3)Папка "Автозагрузка" меню "Пуск". 4)Файлы autorun.inf Такие файлы встречаются на компакт дисках, что позволяет запускать установочную программу диска. Эти файлы также могут располагаться и в корневых директориях жестких дисков, и при обращении к ним инициализируют троян. в файле autorun.inf [autorun] Open= тут_может_быть_троян 5)Файл Autoexec.bat Значит, начинаем определять: частичную картину о том, что у нас находится в автозагрузке нам даст стандартная утилита Windows, "Пуск"->"Выполнить"->msconfig Там мы смотрим закладки "Win.ini", "System.ini" и "Автозагрузка". Далее начинаем смотреть корневые директории дисков (файл может быть скрытым, так что смотреть лучше не при помощи "Проводника", а каким-нибудь FAR'ом). Чаще всего трояны находятся в папках WINDOWS, WINDOWS\SYSTEM, WINDOWS\SYSTEM32 и т.д. В автозагрузке прописывают себя под именем какой-нибудь системной службы. Даже если все убрать из автозагрузки система все равно будет работать, так что не бойтесь что-либо испортить. Далее троян, как и всякая другая программа образует процесс в системе, конечно с помощью Ctrl+Alt+Del вы его не увидите, тут нам поможет Task Spy, с помощью её мы видим все процессы в системе и можем получать детальную информацию о них. Выбираем из списка процесс вызывающий подозрения, жмем "Подробнее..." и смотрим список загруженых модулей. Стоит насторожиться, если в этом списке присутствуют mpr.dll, wsock32.dll, rasapi32.dll, rasman.dll или wininet.dll. Теперь от нас не укроется ни один троян... Теперь будем использовать ошибки, которые допустили троянописатели: 1) У каждого сервера трояна есть свой порт, к которому подключается клиент. Ошибка в том что сервер сразу же при запуске открывает свой порт и ждет соединения, не смотря на то в онлайне находится юзер или нет. Теперь запускаем какой-нибудь файрволл и смотри открытые порты. Тут я привожу список портов и сидящих на них троянов (список отнюдь не полон, но в нем присутствуют самые распространенные): NetBus 1.x (avoiding Netbuster) - 12346 NetBus Pro - 20034 BackOriffice - 31337 SubSeven - 1243 NetSphere - 30100 Deep Throath - 6670 Master Paradise - 31 (40423) Silencer - 1001 Millenium - 20000 Devil 1.03 - 65000 NetMonitor - 7306 Streaming Audio Trojan - 1170 Socket23 - 5000 Socket25 - 30303 Gatecrasher - 6969 Telecommando - 61466 Gjamer- 12076 IcqTrojen - 4950 Priotrity - 16969 Vodoo - 1245 Wincrash - 5742 Wincrash2 - 2583 Netspy - 1033 ShockRave - 1981 Stealth Spy - 555 Pass Ripper - 2023 Attack FTP - 666 GirlFriend - 21554 Fore - 50766 DeltaSource (DarkStar) - 6883 Tiny Telnet Server - 34324 Kuang - 30999 SennaSpyTrojans - 11000 Backdoor - 1999 WebEx - 1001 UglyFtp - 23456 TrojanCow - 2001 TheSpy - 40412 Striker - 2565 Silencer - 1001 RoboHack - 5569 RemoteWindowsShutdown - 53001 Prosiak 0.47 - 22222 ProgenicTrojan - 11223 PortalOfDoom - 9872 (9875) InIkiller - 9989 IcqTrojan - 4950 BladeRunner - 5400 The tHing - 6400 PsyberStreamingServer Nikhil G. - 1509 Phineas Nikhil G. - 2801 Wingate (Socks-Proxy) - 1080 Теперь определяем IP хозяина (по IP, как известно многое можно узнать): запускаем файрволл и когда мы в онлайне следим за портом, на котором сидит троян и при подключении к нему файрволл нам покажет IP хозяина. Важно правильно настроить файрволл. 2)Троянописатели (повторяю не все) с кривыми руками не удосужились даже создать обработку исключительных ситуаций в троянах. Большинство троянов отказывается идти под XP пишет "Точка входа в процедуру WNetEnumCachedPasswords не найдена в библиотеке DLL mpr.dll". Если вы такое заметили - это троян. 3) Если троян почтовый, то попробуем определить имя почтового ящика хозяина, оно нам о многом скажет. Опять же большинство троянописателей не потрудились даже придумать хоть какую-то систему шифрования. Берем какой-нибудь декомпилятор, к примеру DeDe, открываем в нем файл сервера трояна и ищем стороку похожую на e-mail, можно искать по значку "@". В большинстве случаев я находил. Аудит Брандмауэров и Средств обнаружения вторжений (IDS). Часть первая. Дон Паркер, перевод Владимир Куксенок С сегодняшним уровнем угрозы из внешней среды, наличия брандмауэра и IDS (Intrusion Detection System - Средство Обнаружения Вторжений) у домашнего или корпоративного пользователя это больше не роскошь, а скорее необходимость. И все же, многие люди не уделяют время для проверки того, что эти средства защиты действительно работают правильно. В конце конов очень просто дискредитировать весь набор правил вашего маршрутизатора, создав всего одно непродуманное правило. То же самое можно сказать о вашем брандмауэре, из-за одного слабого правила, например для вашего iptables, вы может остаться уязвимы. Правильно ли вы настроили некоторые опции вашего брандмауэра? На этот вопрос можно ответить, и что более важно проверить самому с помощью пакетного тестирования. Это позволит вам вручную проверить, правильно ли сконфигурированы ваш брандмауэр и IDS. Лучше всего не полагаться вслепую на вывод некоторых автоматизированных утилит при проверке устройств, защищающих ваши компьютеры. Можно провести аналогию, где человек проверяет, закрыта ли дверь и выключен ли газ, вместо того, чтобы ждать грабителя или пожарной тревоги. Вы знаете, что сделали все необходимое, для защиты вашего периметра, но все же хотите удостовериться еще больше. Пакетное тестирование, используемое для аудита сети, не может проверить все ситуации, возможные с вашим брандмауэром и IDS, но может смоделировать необходимое их количество. Эта статья - первая из двух частей, описывает различные способы проверки надежности вашего брандмауэра и IDS, используя низкоуровневые утилиты и методы создания TCP/IP пакетов. Я использовал Linux систему, но все описанное будет так же работать и на других Unix-подобных системах. Преимущества Пакетного тестирования (Packet Crafting) Существуют некоторые дополнительные выгоды при изучения способов аудита вашего брандмауэра и IDS, используя пакетное тестирование. Что бы научиться эффективно использовать утилиты типа hping и правильно интерпретировать их данные, вы заставляете себя больше изучать TCP/IP. Глубокое изучение основы компьютерных коммуникаций, пакетов, является хорошей целью для любого, желающего увеличить свои знания о компьютерах. Сказав это, я не буду предполагать, что все читатели этой статьи имеют хорошие знания о TCP/IP. По ходу этой статьи, информация, полученная от используемых программ, будет детально объясняться. Весь вывод Snort и tcpdump будет описан ясно и кратко. Вы можете сказать, что здесь могло бы быть больше информации для углубленного понимания TCP/IP, но эта статья о том, как научиться тестировать правила вашего брандмауэра и IDS. Будет показано несколько примеров и для брандмауэра и для IDS. Поскольку этот документ предназначен для того, чтобы показать, как работать с hping, Snort и tcpdump, будет присутствовать несколько универсальных примеров. Поэтому, нижеупомянутые примеры - хорошая отправная точка. Упражняясь с нижеизложенной информацией, вы должны чувствовать себя достаточно комфортно, чтобы эффективно протестировать ваш собственный брандмауэр и IDS. Обратите внимание, что есть автоматизированные утилиты, которые могут сделать все это за вас. Тем не менее, очень важно, чтобы вы могли сделать все сами, и были способны контролировать и анализировать результаты. Это даст вам чувство уверенности, знание, что защита вашего периметра работает так, как рекламировалась. Тестирование вашего брандмауэра - первый пример Сейчас мы начнем с нескольких примеров того, как проверить ваш брандмауэр в различных условиях. Вначале нужно проверить виден ли 80 порт через брандмауэр. Второй пример проверит, открыт ли 53 порт, и затем мы завершим первую часть этой статьи. Допущение Пожалуйста, обратите внимание на то, что эти тесты проводились на SuSE Linux Professional 9.0 со стандартным набором правил iptables. Я не привожу здесь пример синтаксиса IPTables, т.к. вместо него вы можете использовать IPChains, какой-либо другой брандмауэр, возможно коммерческий брандмауэр или даже другой тип решения. Также, было бы сложно убрать правило, от которого зависят все остальные, что и послужило основной причиной не приводить здесь примеры синтаксиса правил. И, наконец, каждая проверка будет объясняться, чтобы вы могли понять, в каком контексте происходит тестирование. Во второй части мы рассмотрим Snort 2.1.0 со стандартным набором правил. Пример ниже показывает пакет, посланный на 80 порт. Как и должно быть в соответствии с конфигурацией нашего брандмауэра, пакет блокируется. Нормальным поведение TCP пакета, посланного на порт, который не прослушивается никаким сервисом, было бы отправка назад на исходный компьютер. Ниже показана информация, скопированная из окна моего терминала и синтаксис запуска hping. Я опишу параметры hping, задействованные в этом примере, и далее, если не будет больших различий в синтаксисе, уточнять их не буду. hping Имя программы, для создания пакетов -S Говорим hping отослать SYN пакет 192.168.1.108 Указываем адрес получателя, на который будет отправлен SYN пакет -p 80 Указываем порт на компьютере получателя, в нашем случае это порт 80 -c 1 Этот параметр задает количество отправляемых пакетов, в нашем случае это 1 Обратите внимание на вывод hping. В нем показан только адрес получателя, то, что установлен флаг S (SYN пакет), что размер пакета 40 байт (стандартный размер TCP/IP заголовка) и 0 байт данных в пакете. Оставшаяся часть вывода hping это, как показано ниже, статистика пакета, созданного вами с помощью hping. Здесь говорится, что был отправлен 1 пакет, 0 пакетов было получено назад, и что 100% пакетов были потеряны. Также указано время пути туда и обратно, если хотя бы 1 пакет был отправлен назад. monkeylabs:/home/don # hping -S 192.168.1.108 -p 80 -c 1 HPING 192.168.1.108 (eth0 192.168.1.108): S set, 40 headers + 0 data bytes --- 192.168.1.108 hping statistic --- 1 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms Используя вышеупомянутую команду, смотрите ниже, как выглядит пакет, созданный с помощью hping и отсылаемый с локальной машины. Теперь опишем синтаксис вызова tcpdump. tcpdumpИмя программы -n Указываем, что IP адрес будет в числовом формате X Указываем, что представлять информацию нужно в HEX и ASCII формате. v Более подробный вывод: показывать все информацию о пакете s Включаем перехват пакетов определенной длинны 0 Если вы укажете 0, tcpdump будет захватывать пакеты с длинной по умолчания для вашего компьютера. В моем случае это 1518. tcp Указываем, что хотим перехватывать только TCP пакеты, не UDP или ICMP, только TCP. and host 192.168.1.100 Указываем, что хотим перехватывать пакеты от 192.168.1.100 and 192.168.1.108 и от 192.168.1.108 Использование двух вышеупомянутых IP адресов с указанными параметрами вызова tcpdump позволяет перехватывать только пакеты, проходящие между 192.168.1.100 и 192.168.1.108. Это позволит не перехватывать ненужные нам пакеты, например, от DNS сервера вашего ISP или ARP пакеты вашего коммутатора. Чтобы помочь вам в чтении данных вывода tcpdump, ниже я опишу все поля пакета, так же как я описывал синтаксис вызова tcpdump. Мы увидим, что означает каждое поле, начиная с поля времени. 10:07:30.171332 Время, когда пакет был получен 192.168.1.100.1321 IP адрес и порт отправителя 192.168.1.108.80 IP адрес и порт получателя S Указывает на то, что мы посылаем SYN пакет [tcp sum ok] Контрольная сумма правильная 1907499058:1907499058 Позиционный номер TCP (TCP sequence) (0) Количество байт данных в пакете win 512 Размер окна [tos 0x8]Тип сервиса ttl 64 Число перемещений, за которое пакет должен достигнуть получателя id 45106 Идентификационный номер пакета, используется для сборки пакета после фрагментации len 40 Длинна пакета /home/don # tcpdump -nXvs 0 tcp and host 192.168.1.100 and 192.168.1.108 tcpdump: listening on eth0 10:07:30.171332 192.168.1.100.1321 > 192.168.1.108.80: S [tcp sum ok] 1907499058:1907499058(0) win 512 [tos 0x8] (ttl 64, id 45106, len 40) 0x0000 4508 0028 b032 0000 4006 4675 c0a8 0164 E..(.2..@.Fu...d 0x0010 c0a8 016c 0529 0050 71b2 2032 53e1 85d2 ...l.).Pq..2S... 0x0020 5002 0200 b8b0 0000 P....... Ниже можно увидеть, что происходит на целевом компьютере, когда он получает пакет. По умолчанию он был заблокирован, т.к. на целевом компьютере нет необходимого сервиса, и именно так сконфигурирован iptables для работы с пакетами, посланными на никем не прослушиваемые порты на SuSE. Mar 2 10:06:40 linux kernel: SuSE-FW-DROP-DEFAULT IN=eth0 OUT= MAC=00:50:da:c5:9d:8b:00:0c:6e:8c:d4:61:08:00 SRC=192.168.1.100 DST=192.168.1.108 LEN=40 TOS=0x08 PREC=0x00 TTL=64 ID=45106 PROTO=TCP SPT=1321 DPT=80 WINDOW=512 RES=0x00 SYN URGP=0 Это пакет, достигший тестируемой машины. Как мы видим, все нормально: /home/don # tcpdump -nXvs 0 tcp and host 192.168.1.108 and 192.168.1.100 tcpdump: listening on eth0 10:06:40.474204 192.168.1.100.1321 > 192.168.1.108.80: S [tcp sum ok] 1907499058:1907499058(0) win 512 [tos 0x8] (ttl 64, id 45106, len 40) 0x0000 4508 0028 b032 0000 4006 4675 c0a8 0164 E..(.2..@.Fu...d 0x0010 c0a8 016c 0529 0050 71b2 2032 53e1 85d2 ...l.).Pq..2S... 0x0020 5002 0200 b8b0 0000 0000 0000 0000 P............. Итак, мы можем наблюдать, как пакет был отослан, получен тестируемой машиной, но, однако был заблокирован. Тестирование вашего брандмауэра - второй пример, исследование 53 UDP порта Теперь мы будем исследовать 53 UDP порт. Обратите внимание на синтаксис вызова hping, а также на его вывод: monkeylabs:/home/don # hping -2 192.168.1.108 -p 53 -c 1 HPING 192.168.1.108 (eth0 192.168.1.108): udp mode set, 28 headers + 0 data bytes --- 192.168.1.108 hping statistic --- 1 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms monkeylabs:/home/don # Только что мы отослали пакет на 53 UDP порт, что посмотреть, заблокирует ли его брандмауэр. Как мы можем видеть из вывода hping и информации от брандмауэра ниже, пакет был заблокирован, т.к. 53 UDP порт закрыт. Mar 2 10:24:30 linux kernel: SuSE-FW-DROP-DEFAULT IN=eth0 OUT= MAC=00:50:da:c5:9d:8b:00:0c:6e:8c:d4:61:08:00 SRC=192.168.1.100 DST=192.168.1.108 LEN=28 TOS=0x10 PREC=0x00 TTL=64 ID=47873 PROTO=UDP SPT=2180 DPT=53 LEN=8 Это пакет, который был получен на тестируемом компьютере: /home/don # tcpdump -nXvs 0 udp and host 192.168.1.108 and 192.168.1.100 tcpdump: listening on eth0 10:24:30.172588 192.168.1.100.2180 > 192.168.1.108.53: [udp sum ok] 0 [0q] (0) [tos 0x10] (ttl 64, id 47873, len 28) 0x0000 4510 001c bb01 0000 4011 3b9f c0a8 0164 E.......@.;....d 0x0010 c0a8 016c 0884 0035 0008 7304 0000 0000 ...l...5..s..... 0x0020 0000 0000 0000 0000 0000 0000 0000 ............. Это пакет, который был отправлен с компьютера, который мы используем для проверки защищенности брандмауэра: monkeylabs:/home/don # tcpdump -nXvs 0 udp and host 192.168.1.100 and 192.168.1.108 tcpdump: listening on eth0 10:25:19.887529 192.168.1.100.2180 > 192.168.1.108.53: [udp sum ok] [|domain] [tos 0x10] (ttl 64, id 47873, len 28) 0x0000 4510 001c bb01 0000 4011 3b9f c0a8 0164 E.......@.;....d 0x0010 c0a8 016c 0884 0035 0008 7304 ...l...5..s. Нормальным поведением, в случае, когда UDP пакет отправлен на не прослушиваемый порт, является отправка ICMP сообщения о том, что порт недоступен. В нашем случае этого не происходит, потому что на тестируемом компьютере в конфигурации iptables установлена "тихая" блокировка этого типа пакетов (т.е. без отправки соответствующего ICMP сообщения об ошибке). Как вы видите, пакетное тестирование это отличный способ проверки конфигурации вашего брандмауэра. Особенно для сложных и запутанных конфигураций, какой, к примеру, может стать набор правил IPTables. В заключение первой части Мы рассмотрели два примера исследования вашего брандмауэра с использованием hping и tcpdump. В следующий раз, во второй части этой серии статей мы рассмотрим другой пример тестирования брандмауэра, а затем начнем тестирование IDS Snort, используя методы описанные здесь. Будьте защищенными.