Как-то раз, вернувшись из отпуска, вдоволь натунеядствовавшись, решил я сваять что-то божественное на PHP. Открыл свой любимый Denwer и поразился неожиданной перемене: Apache напрочь отказался слушать 80-й порт, а значит, мои благородные намерения на этот вечер оказались под угрозой срыва. Ситуация, в общем-то, довольно банальная — сразу же в голове сработал заветный триггер: Skype! Однако к моему удивлению, Skype тут же объявил о своей непричастности к данному инциденту отсутствием галочки напротив соответствующей настройки. Чтобы окончательно проверить алиби зарубежного видеотелефона я решил посмотреть, кто же все-таки в данный момент слушает 80-й порт.
Увиденное не прибавило мне оптимизма, а, скорее, заставило почесать макушку в задумчивости:
Стало понятно — на компьютере действуют незаконные вооруженные бандформирования. Причем действуют партизанскими методами, так как PID=4 принадлежал процессу System.
Первая мысль пришла совершенно случайно: если порт кто-то слушает, то возможно он туда что-то и отвечает, потому, вооружившись связкой Firefox+Firebug, я послал запрос на localhost. Как ни странно шальная мысль дала свои плоды. Неведомый враг ответил:
Итак имя подозреваемого (или его сообщника) прояснилось: Microsoft-HTTPAPI/2.0. Зверь для меня новый, до этого момента незнакомый, потому решено было отправится на просторы всемирной паутины за информацией. Гугление, вопросы в Хабр-Q&A и askdev.ru в общем, особой пользы не принесли. В основном народ указывал на некий Reporting Services из состава MS SQL Server либо остатки IIS в системе. Ни того, ни другого у меня отродясь не было (хотя на всякий случай я все же проверил эти версии усиленным поиском по именам файлов). Так что перспектива вырисовывалась нерадужная — троян или червячок. Следующие несколько дней (точнее вечеров) я провел в безуспешных поисках «нежелательного программного обеспечения» при помощи различного антивирусного ПО. Результатов не было. Вдалеке замаячил призрак полной переустановки системы.
Вместе с тем, вопросы к уважаемому сообществу не были напрасны: один товарищ предложил тупо удалить файл c:\Windows\System32\httpapi.dll, так как именно он ответственен за все чинимые беззакония. Удалять библиотеку, я конечно, не стал, однако файлик взял на заметку. Обвешавшись утилитами от SysInternals, я ринулся в бой:
tasklist — это стандартная утилита Windows, в сущности, консольный Диспетчер Задач. С ключом /M позволяет увидеть какие процессы используют заданную библиотеку. Стали ясны «непосредственные исполнители». Далее запустив Process Explorer от SysInternals, я нашел процессы с заданными идентификаторами. Открыв диалог свойств, на вкладке Services я увидел довольно много различных служб Windows, которые были зарегистрированы в данных процессах. Служб было много, так что выбора не было — я отключил все, чтобы просто проверить правильность своей догадки. Среди служб были такие: Смарт-карта, BranchCache, Политика удаления смарт-карт, прослушиватель домашней группы, Обнаружение SSDP, Хост поставщика функции обнаружения и пр. Всего около 15. После перезагрузки у меня отказалась работать локальная сеть (правда интеренет все-таки работал), однако к моей радости 80-й порт освободился. После этого оставалась рутина: поочередно включать только что отключенные службы и проверять, не занят ли 80-й порт. Тут необходимо сделать небольшую ремарку: то, что несколько служб зарегистрировано в процессе, который слушает некий порт, совсем не означает, что все эти службы слушают этот порт. Просто они оказались «не в то время, не в том месте». Таким образом злоумышленник был выявлен достаточно точно: им оказалась служба BranchCache, которая, как следует из описания: кэширует сетевое содержимое, полученное от кэширующих узлов локальной подсети.
Ну а дальше — дело техники. В MSDN было нарыто руководство по BranchCache, из которого следовало, что BranchCache может работать в различных режимах: выделенного сервера (в качестве сервера нужна машина с Windows Server 2008 R2) и распределенного хранения (может работать на обычных версиях Windows 7). Соответственно предстояло выполнить две вещи: сменить порт и установить режим работы в качестве распределенного хранилища:
После этого включаем обратно BranchCache и удостоверяемся, что 80-й порт свободен (теперь слушается порт 4455). Боевая задача успешно выполнена.
UPD: По просьбам товарищей в комментариях, сообщаю, что BranchCache — это обычная служба Windows. Отключить ее можно поставив Тип запуска: «Отключена» в параметрах. По умолчанию, эта служба имеет тип запуска «Вручную» и запускается по требованию приложений. Так что у большинства пользователей она должна быть отключена сразу.
Увиденное не прибавило мне оптимизма, а, скорее, заставило почесать макушку в задумчивости:
Активные подключения
Имя Локальный адрес Внешний адрес Состояние PID
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
Не удается получить сведения о владельце
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 900
RpcSs
[svchost.exe]
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
Не удается получить сведения о владельце
TCP 0.0.0.0:990 0.0.0.0:0 LISTENING 2428
WcesComm
[svchost.exe]
TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING 4
Не удается получить сведения о владельцеСтало понятно — на компьютере действуют незаконные вооруженные бандформирования. Причем действуют партизанскими методами, так как PID=4 принадлежал процессу System.
Первая мысль пришла совершенно случайно: если порт кто-то слушает, то возможно он туда что-то и отвечает, потому, вооружившись связкой Firefox+Firebug, я послал запрос на localhost. Как ни странно шальная мысль дала свои плоды. Неведомый враг ответил:
Заголовки ответа
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 25 Sep 2010 11:20:20 GMT
Connection: close
Content-Length: 315Итак имя подозреваемого (или его сообщника) прояснилось: Microsoft-HTTPAPI/2.0. Зверь для меня новый, до этого момента незнакомый, потому решено было отправится на просторы всемирной паутины за информацией. Гугление, вопросы в Хабр-Q&A и askdev.ru в общем, особой пользы не принесли. В основном народ указывал на некий Reporting Services из состава MS SQL Server либо остатки IIS в системе. Ни того, ни другого у меня отродясь не было (хотя на всякий случай я все же проверил эти версии усиленным поиском по именам файлов). Так что перспектива вырисовывалась нерадужная — троян или червячок. Следующие несколько дней (точнее вечеров) я провел в безуспешных поисках «нежелательного программного обеспечения» при помощи различного антивирусного ПО. Результатов не было. Вдалеке замаячил призрак полной переустановки системы.
Вместе с тем, вопросы к уважаемому сообществу не были напрасны: один товарищ предложил тупо удалить файл c:\Windows\System32\httpapi.dll, так как именно он ответственен за все чинимые беззакония. Удалять библиотеку, я конечно, не стал, однако файлик взял на заметку. Обвешавшись утилитами от SysInternals, я ринулся в бой:
C:\Windows\system32>tasklist /M httpapi.dll
Имя образа PID Модули
========================= ======== ============================================
svchost.exe 1328 HTTPAPI.dll
svchost.exe 2628 HTTPAPI.dll
svchost.exe 3856 HTTPAPI.dlltasklist — это стандартная утилита Windows, в сущности, консольный Диспетчер Задач. С ключом /M позволяет увидеть какие процессы используют заданную библиотеку. Стали ясны «непосредственные исполнители». Далее запустив Process Explorer от SysInternals, я нашел процессы с заданными идентификаторами. Открыв диалог свойств, на вкладке Services я увидел довольно много различных служб Windows, которые были зарегистрированы в данных процессах. Служб было много, так что выбора не было — я отключил все, чтобы просто проверить правильность своей догадки. Среди служб были такие: Смарт-карта, BranchCache, Политика удаления смарт-карт, прослушиватель домашней группы, Обнаружение SSDP, Хост поставщика функции обнаружения и пр. Всего около 15. После перезагрузки у меня отказалась работать локальная сеть (правда интеренет все-таки работал), однако к моей радости 80-й порт освободился. После этого оставалась рутина: поочередно включать только что отключенные службы и проверять, не занят ли 80-й порт. Тут необходимо сделать небольшую ремарку: то, что несколько служб зарегистрировано в процессе, который слушает некий порт, совсем не означает, что все эти службы слушают этот порт. Просто они оказались «не в то время, не в том месте». Таким образом злоумышленник был выявлен достаточно точно: им оказалась служба BranchCache, которая, как следует из описания: кэширует сетевое содержимое, полученное от кэширующих узлов локальной подсети.
Ну а дальше — дело техники. В MSDN было нарыто руководство по BranchCache, из которого следовало, что BranchCache может работать в различных режимах: выделенного сервера (в качестве сервера нужна машина с Windows Server 2008 R2) и распределенного хранения (может работать на обычных версиях Windows 7). Соответственно предстояло выполнить две вещи: сменить порт и установить режим работы в качестве распределенного хранилища:
REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\PeerDist\DownloadManager\Peers\Connection" /v ListenPort /t REG_DWORD /d 4455 /f
REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\PeerDist\DownloadManager\Peers\Connection" /v ConnectPort /t REG_DWORD /d 4455 /f
netsh br set service mode=distributedПосле этого включаем обратно BranchCache и удостоверяемся, что 80-й порт свободен (теперь слушается порт 4455). Боевая задача успешно выполнена.
UPD: По просьбам товарищей в комментариях, сообщаю, что BranchCache — это обычная служба Windows. Отключить ее можно поставив Тип запуска: «Отключена» в параметрах. По умолчанию, эта служба имеет тип запуска «Вручную» и запускается по требованию приложений. Так что у большинства пользователей она должна быть отключена сразу.
