Перезагрузки компьютера под управлением Windows XP. Часть 2.
День второй.
Как я в прошлый раз и предполагал, снова позвали :)
Получается, в общем-то, файр был не виновен. Поэтому не вдаваясь в детали, поставил другой фаер (COMODO) и просмотрел логи модема. Что там было:
Jan 1 00:00:22daemoninfopppd[247]: Plugin pppoe loaded. Jan 1 00:00:22daemoninfopppd[247]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.3 Jan 1 00:00:22daemoninfopppd[247]: Plugin pppoe called. Jan 1 00:00:22usercritkernel: ADSL G.992 channel analysis Jan 1 00:00:23daemonnoticepppd[247]: pppd 2.4.3 started by admin, uid 0 Jan 1 00:00:28usercritkernel: ADSL G.992 message exchange Jan 1 00:00:29usercritkernel: ADSL link up, interleaved, us=636, ds=1020 Jan 1 00:00:29userwarnkernel: ATM Soft SAR: ATM link connected. Jan 1 00:00:31userdebugsyslog: iptables -t nat -A PREROUTING -i br0 -d 192.168.1.1 -p udp --dport 53 -j DNAT --to 128.9.0.107 Jan 1 00:01:10daemonwarnpppd[247]: Timeout waiting for PADO packets Jan 1 00:01:11daemonerrpppd[247]: Unable to complete PPPoE Discovery Jan 1 00:01:55daemonwarnpppd[247]: Timeout waiting for PADO packets Jan 1 00:01:56daemonerrpppd[247]: Unable to complete PPPoE Discovery Jan 1 00:02:00daemoninfopppd[247]: PPP session is 5687 Jan 1 00:02:00daemoninfopppd[247]: Using interface ppp0_89_129_1 Jan 1 00:02:00daemonnoticepppd[247]: Connect: ppp_0_89_129_1 <--> nas_0_89_129 Jan 1 00:02:00daemonwarnpppd[247]: Couldn't increase MRU to 1500 Jan 1 00:02:00daemonwarnpppd[247]: Couldn't increase MRU to 1500 Jan 1 00:02:00daemonnoticepppd[247]: PAP authentication succeeded Jan 1 00:02:00daemonnoticepppd[247]: peer from calling number 00:90:1A:41:FD:FF authorized Jan 1 00:02:00daemonnoticepppd[247]: local IP address 95.188.168.169 Jan 1 00:02:00daemonnoticepppd[247]: remote IP address 213.228.116.164 Jan 1 00:02:00daemonnoticepppd[247]: primary DNS address 90.189.109.4 Jan 1 00:02:00daemonnoticepppd[247]: secondary DNS address 195.112.224.75 Jan 1 00:02:08userdebugsyslog: route add default gw 213.228.116.164 2>/dev/null Jan 1 00:02:09userdebugsyslog: iptables -A FORWARD -o ppp_0_89_129_1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu Jan 1 00:02:09userdebugsyslog: iptables -A FORWARD -i ppp_0_89_129_1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu Jan 1 00:02:09userdebugsyslog: echo > /proc/net/ip_conntrack Jan 1 00:02:09userdebugsyslog: echo "1000" > /proc/sys/net/ipv4/ip_conntrack_max Jan 1 00:02:09userdebugsyslog: iptables -t nat -D PREROUTING -i br0 -d 192.168.1.1 -p udp --dport 53 -j DNAT --to 128.9.0.107 2>/dev/null Jan 1 00:02:10userdebugsyslog: iptables -t nat -D POSTROUTING -o ppp_0_89_129_1 -s 192.168.1.0/255.255.255.0 -j MASQUERADE 2>/dev/null Jan 1 00:02:10userdebugsyslog: iptables -t nat -A POSTROUTING -o ppp_0_89_129_1 -s 192.168.1.0/255.255.255.0 -j MASQUERADE Mar 27 12:53:33userdebugsyslog: kill -9 241 Mar 27 12:53:33userdebugsyslog: echo > /var/hosts Mar 27 12:54:29useralertkernel: Intrusion -> IN=ppp_0_89_129_1 OUT= MAC= SRC=95.188.177.2 DST=95.188.168.169 LEN=60 TOS=0x08 PREC=0xC0 TTL=62 ID=14624 PROTO=TCP SPT=1051 DPT=135 WINDOW=65535 RES=0x00 SYN URGP=0 Mar 27 12:56:16userwarnkernel: AdslCoreEcUpdTmr: timeMs=1800055 ecUpdMask=0x40000 Mar 27 12:59:04useralertkernel: Intrusion -> IN=ppp_0_89_129_1 OUT= MAC= SRC=95.48.27.236 DST=95.188.168.169 LEN=48 TOS=0x08 PREC=0xC0 TTL=116 ID=3189 DF PROTO=TCP SPT=6246 DPT=135 WINDOW=65535 RES=0x00 SYN URGP=0 Mar 27 12:59:16useralertkernel: Intrusion -> IN=ppp_0_89_129_1 OUT= MAC= SRC=88.119.42.94 DST=95.188.168.169 LEN=48 TOS=0x08 PREC=0xC0 TTL=121 ID=10189 DF PROTO=TCP SPT=4552 DPT=59451 WINDOW=16384 RES=0x00 SYN URGP=0 Mar 27 12:59:19useralertkernel: Intrusion -> IN=ppp_0_89_129_1 OUT= MAC= SRC=88.119.42.94 DST=95.188.168.169 LEN=48 TOS=0x08 PREC=0xC0 TTL=121 ID=10219 DF PROTO=TCP SPT=4552 DPT=59451 WINDOW=16384 RES=0x00 SYN URGP=0 Mar 27 12:59:25useralertkernel: Intrusion -> IN=ppp_0_89_129_1 OUT= MAC= SRC=88.119.42.94 DST=95.188.168.169 LEN=48 TOS=0x08 PREC=0xC0 TTL=121 ID=10245 DF PROTO=TCP SPT=4552 DPT=59451 WINDOW=16384 RES=0x00 SYN URGP=0 Mar 27 13:01:13userdebugsyslog: ethctl eth0 vport query 2>/var/vcfgerr Mar 27 13:01:14userdebugsyslog: rm /var/vcfgerr Mar 27 13:01:18userdebugsyslog: ethctl eth0 vport query 2>/var/vcfgerr Mar 27 13:01:18userdebugsyslog: rm /var/vcfgerr Mar 27 13:01:25userdebugsyslog: ethctl vport query 2>/var/vcfgerr Mar 27 13:01:25userdebugsyslog: rm /var/vcfgerr Mar 27 13:01:27usercritkernel: OAM loopback response not received on PORT/VPI/VCI 0/89/129. Mar 27 13:01:29usercritkernel: OAM loopback response not received on PORT/VPI/VCI 0/89/129. Mar 27 13:01:29userdebugsyslog: ping 213.228.116.164 Mar 27 13:01:30userdebugsyslog: ping 90.189.109.4
Как видно (даже по цветам :), по 135, 59451 портам наблюдается подозрительная активность, причём с разных IP. Ситуация очень похожа на моё вчерашнее предположение о вирусах в подсети провайдера. Только, с учётом того, что ипы динамические, навряд ли кто-то специально бомбит модем запросами; скорее всего, есть несколько заражённых компов в сети провайдера, которые пытаются заразить соседние компьютеры.
Позвонил провайдеру в техподдержку, мне ответили, что у них "невозможны никакие сетевые атаки, перезагрузки не могут быть связаны с модемом."
Поменял пароль администратора на модеме и пошёл на работу (забегал буквально на полчаса, на обеденном перерыве). Пока возвращался на работу, решил поставить 3-й сервис-пак для XP.
День третий.
Через некоторое время снова повторилась ситуация с перезагрузкой. Ну, окончательно решил поставить SP3. Во всяком случае, жизненно важные системные файлы должны перезаписаться. Начал ставить SP в Safe Mode (на всякий пожарный). Тут меня поджидала одна очень каверзная штука. Не уверен, связано это с Безопасным Режимом или с деятельностью руткита, но ситуация была не очень приятная. Заключалась она вот в чём.
Во время установки сервис-пака выскочила ошибка: "Не удаётся скопировать раздел реестра HKCR/Psisdecd.ATSCTerrestrial/CLSID в "путь_папки_на_диске". Ошибка чтения." И действительно, захожу в реестр, данный раздел недоступен. А также следующие разделы:
HKCR/Psisdecd.ATSCTerrestrial/CLSID
HKCR/Psisdecd.ATSCTerrestrial.1/CLSID
HKCR/Psisdecd.CDvb/CLSID
HKCR/Psisdecd.CDvb.1/CLSID
HKCR/Psisdecd.OpenCable/CLSID
HKCR/Psisdecd.OpenCable.1/CLSID
не были доступны для записи.
Как я это дело исправил:
1. Пытаюсь изменить права на запись. Не удаётся :(
2. Пытаюсь изменить владельца раздела. Не удаётся :(
3. Пытаюсь переименовать корневой раздел:
HKCR/Psisdecd.ATSCTerrestrial, например, в HKCR/Psisdecd.ATSCTerrestrial_1.
Переименование не удаётся. Но (как оказалось дальше) это уже хорошо :)
4. Теперь снова пытаюсь сменить владельца раздела. Ура! Успех!
5. Меняю права на раздел.
6. Но я не вижу, бля, CLSID :(
7. Поэтому, попробую создать подраздел в HKCR/Psisdecd.ATSCTerrestrial. Любой.
Ура! Раздел создался, и Ура2!, стал виден CLSID.
8. Меняю владельца, разрешения на CLSID, удаляю созданный мной раздел.
9. Повторяю операцию для остальных разделов.
Всё, сервиспак встал. Перезагружаюсь, делаю ntbackup. Потом включаю модем, смотрю логи фаера - ничего подозрительного нет. Хм, переключаю модем в bridging-mode, и соединяюсь теперь уже через установление pppoe-соединения на компьютере. Опа! А вот и первый запрос с левого адреса отсёкся. Ну, сказал владельцу компа, чтобы на все подозрительные запросы выбирал "Заблокировать". Надо будет настроить, чтобы комод без вопросов отрабатывал подобные ситуации.
Ну вот, сегодня уже 2-й день, пока полёт нормальный.
День Х (будущий).
Что надо бы ещё в идеале сделать у моего френда с компом?
1. Приучить его работать с правами User :)
2. Если бы была лицензионная винда, то включить автоматические обновления;
3. Закрыть дыру 17-летней давности, описанную тут: http://www.xakep.ru/post/50830/default.asp
gpedit.msc->Конфигурация компьютера->Административные шаблоны->Компоненты Windows->Совместимость приложений->Предотвращение доступа к 16-разрядным приложениям->Включен.
Как я в прошлый раз и предполагал, снова позвали :)
Получается, в общем-то, файр был не виновен. Поэтому не вдаваясь в детали, поставил другой фаер (COMODO) и просмотрел логи модема. Что там было:
Jan 1 00:00:22daemoninfopppd[247]: Plugin pppoe loaded. Jan 1 00:00:22daemoninfopppd[247]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.3 Jan 1 00:00:22daemoninfopppd[247]: Plugin pppoe called. Jan 1 00:00:22usercritkernel: ADSL G.992 channel analysis Jan 1 00:00:23daemonnoticepppd[247]: pppd 2.4.3 started by admin, uid 0 Jan 1 00:00:28usercritkernel: ADSL G.992 message exchange Jan 1 00:00:29usercritkernel: ADSL link up, interleaved, us=636, ds=1020 Jan 1 00:00:29userwarnkernel: ATM Soft SAR: ATM link connected. Jan 1 00:00:31userdebugsyslog: iptables -t nat -A PREROUTING -i br0 -d 192.168.1.1 -p udp --dport 53 -j DNAT --to 128.9.0.107 Jan 1 00:01:10daemonwarnpppd[247]: Timeout waiting for PADO packets Jan 1 00:01:11daemonerrpppd[247]: Unable to complete PPPoE Discovery Jan 1 00:01:55daemonwarnpppd[247]: Timeout waiting for PADO packets Jan 1 00:01:56daemonerrpppd[247]: Unable to complete PPPoE Discovery Jan 1 00:02:00daemoninfopppd[247]: PPP session is 5687 Jan 1 00:02:00daemoninfopppd[247]: Using interface ppp0_89_129_1 Jan 1 00:02:00daemonnoticepppd[247]: Connect: ppp_0_89_129_1 <--> nas_0_89_129 Jan 1 00:02:00daemonwarnpppd[247]: Couldn't increase MRU to 1500 Jan 1 00:02:00daemonwarnpppd[247]: Couldn't increase MRU to 1500 Jan 1 00:02:00daemonnoticepppd[247]: PAP authentication succeeded Jan 1 00:02:00daemonnoticepppd[247]: peer from calling number 00:90:1A:41:FD:FF authorized Jan 1 00:02:00daemonnoticepppd[247]: local IP address 95.188.168.169 Jan 1 00:02:00daemonnoticepppd[247]: remote IP address 213.228.116.164 Jan 1 00:02:00daemonnoticepppd[247]: primary DNS address 90.189.109.4 Jan 1 00:02:00daemonnoticepppd[247]: secondary DNS address 195.112.224.75 Jan 1 00:02:08userdebugsyslog: route add default gw 213.228.116.164 2>/dev/null Jan 1 00:02:09userdebugsyslog: iptables -A FORWARD -o ppp_0_89_129_1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu Jan 1 00:02:09userdebugsyslog: iptables -A FORWARD -i ppp_0_89_129_1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu Jan 1 00:02:09userdebugsyslog: echo > /proc/net/ip_conntrack Jan 1 00:02:09userdebugsyslog: echo "1000" > /proc/sys/net/ipv4/ip_conntrack_max Jan 1 00:02:09userdebugsyslog: iptables -t nat -D PREROUTING -i br0 -d 192.168.1.1 -p udp --dport 53 -j DNAT --to 128.9.0.107 2>/dev/null Jan 1 00:02:10userdebugsyslog: iptables -t nat -D POSTROUTING -o ppp_0_89_129_1 -s 192.168.1.0/255.255.255.0 -j MASQUERADE 2>/dev/null Jan 1 00:02:10userdebugsyslog: iptables -t nat -A POSTROUTING -o ppp_0_89_129_1 -s 192.168.1.0/255.255.255.0 -j MASQUERADE Mar 27 12:53:33userdebugsyslog: kill -9 241 Mar 27 12:53:33userdebugsyslog: echo > /var/hosts Mar 27 12:54:29useralertkernel: Intrusion -> IN=ppp_0_89_129_1 OUT= MAC= SRC=95.188.177.2 DST=95.188.168.169 LEN=60 TOS=0x08 PREC=0xC0 TTL=62 ID=14624 PROTO=TCP SPT=1051 DPT=135 WINDOW=65535 RES=0x00 SYN URGP=0 Mar 27 12:56:16userwarnkernel: AdslCoreEcUpdTmr: timeMs=1800055 ecUpdMask=0x40000 Mar 27 12:59:04useralertkernel: Intrusion -> IN=ppp_0_89_129_1 OUT= MAC= SRC=95.48.27.236 DST=95.188.168.169 LEN=48 TOS=0x08 PREC=0xC0 TTL=116 ID=3189 DF PROTO=TCP SPT=6246 DPT=135 WINDOW=65535 RES=0x00 SYN URGP=0 Mar 27 12:59:16useralertkernel: Intrusion -> IN=ppp_0_89_129_1 OUT= MAC= SRC=88.119.42.94 DST=95.188.168.169 LEN=48 TOS=0x08 PREC=0xC0 TTL=121 ID=10189 DF PROTO=TCP SPT=4552 DPT=59451 WINDOW=16384 RES=0x00 SYN URGP=0 Mar 27 12:59:19useralertkernel: Intrusion -> IN=ppp_0_89_129_1 OUT= MAC= SRC=88.119.42.94 DST=95.188.168.169 LEN=48 TOS=0x08 PREC=0xC0 TTL=121 ID=10219 DF PROTO=TCP SPT=4552 DPT=59451 WINDOW=16384 RES=0x00 SYN URGP=0 Mar 27 12:59:25useralertkernel: Intrusion -> IN=ppp_0_89_129_1 OUT= MAC= SRC=88.119.42.94 DST=95.188.168.169 LEN=48 TOS=0x08 PREC=0xC0 TTL=121 ID=10245 DF PROTO=TCP SPT=4552 DPT=59451 WINDOW=16384 RES=0x00 SYN URGP=0 Mar 27 13:01:13userdebugsyslog: ethctl eth0 vport query 2>/var/vcfgerr Mar 27 13:01:14userdebugsyslog: rm /var/vcfgerr Mar 27 13:01:18userdebugsyslog: ethctl eth0 vport query 2>/var/vcfgerr Mar 27 13:01:18userdebugsyslog: rm /var/vcfgerr Mar 27 13:01:25userdebugsyslog: ethctl vport query 2>/var/vcfgerr Mar 27 13:01:25userdebugsyslog: rm /var/vcfgerr Mar 27 13:01:27usercritkernel: OAM loopback response not received on PORT/VPI/VCI 0/89/129. Mar 27 13:01:29usercritkernel: OAM loopback response not received on PORT/VPI/VCI 0/89/129. Mar 27 13:01:29userdebugsyslog: ping 213.228.116.164 Mar 27 13:01:30userdebugsyslog: ping 90.189.109.4
Как видно (даже по цветам :), по 135, 59451 портам наблюдается подозрительная активность, причём с разных IP. Ситуация очень похожа на моё вчерашнее предположение о вирусах в подсети провайдера. Только, с учётом того, что ипы динамические, навряд ли кто-то специально бомбит модем запросами; скорее всего, есть несколько заражённых компов в сети провайдера, которые пытаются заразить соседние компьютеры.
Позвонил провайдеру в техподдержку, мне ответили, что у них "невозможны никакие сетевые атаки, перезагрузки не могут быть связаны с модемом."
Поменял пароль администратора на модеме и пошёл на работу (забегал буквально на полчаса, на обеденном перерыве). Пока возвращался на работу, решил поставить 3-й сервис-пак для XP.
День третий.
Через некоторое время снова повторилась ситуация с перезагрузкой. Ну, окончательно решил поставить SP3. Во всяком случае, жизненно важные системные файлы должны перезаписаться. Начал ставить SP в Safe Mode (на всякий пожарный). Тут меня поджидала одна очень каверзная штука. Не уверен, связано это с Безопасным Режимом или с деятельностью руткита, но ситуация была не очень приятная. Заключалась она вот в чём.
Во время установки сервис-пака выскочила ошибка: "Не удаётся скопировать раздел реестра HKCR/Psisdecd.ATSCTerrestrial/CLSID в "путь_папки_на_диске". Ошибка чтения." И действительно, захожу в реестр, данный раздел недоступен. А также следующие разделы:
HKCR/Psisdecd.ATSCTerrestrial/CLSID
HKCR/Psisdecd.ATSCTerrestrial.1/CLSID
HKCR/Psisdecd.CDvb/CLSID
HKCR/Psisdecd.CDvb.1/CLSID
HKCR/Psisdecd.OpenCable/CLSID
HKCR/Psisdecd.OpenCable.1/CLSID
не были доступны для записи.
Как я это дело исправил:
1. Пытаюсь изменить права на запись. Не удаётся :(
2. Пытаюсь изменить владельца раздела. Не удаётся :(
3. Пытаюсь переименовать корневой раздел:
HKCR/Psisdecd.ATSCTerrestrial, например, в HKCR/Psisdecd.ATSCTerrestrial_1.
Переименование не удаётся. Но (как оказалось дальше) это уже хорошо :)
4. Теперь снова пытаюсь сменить владельца раздела. Ура! Успех!
5. Меняю права на раздел.
6. Но я не вижу, бля, CLSID :(
7. Поэтому, попробую создать подраздел в HKCR/Psisdecd.ATSCTerrestrial. Любой.
Ура! Раздел создался, и Ура2!, стал виден CLSID.
8. Меняю владельца, разрешения на CLSID, удаляю созданный мной раздел.
9. Повторяю операцию для остальных разделов.
Всё, сервиспак встал. Перезагружаюсь, делаю ntbackup. Потом включаю модем, смотрю логи фаера - ничего подозрительного нет. Хм, переключаю модем в bridging-mode, и соединяюсь теперь уже через установление pppoe-соединения на компьютере. Опа! А вот и первый запрос с левого адреса отсёкся. Ну, сказал владельцу компа, чтобы на все подозрительные запросы выбирал "Заблокировать". Надо будет настроить, чтобы комод без вопросов отрабатывал подобные ситуации.
Ну вот, сегодня уже 2-й день, пока полёт нормальный.
День Х (будущий).
Что надо бы ещё в идеале сделать у моего френда с компом?
1. Приучить его работать с правами User :)
2. Если бы была лицензионная винда, то включить автоматические обновления;
3. Закрыть дыру 17-летней давности, описанную тут: http://www.xakep.ru/post/50830/default.asp
gpedit.msc->Конфигурация компьютера->Административные шаблоны->Компоненты Windows->Совместимость приложений->Предотвращение доступа к 16-разрядным приложениям->Включен.