[масон]

Вот так же и здесь. Сетевой стек Висты включает в себя следующие протоколы:

ICMP;
IGMP;
IPv4;
IPv6;
ICMPv6;
TCP;
UDP;
IP6;
GRE;
ESP;
AH;
43;
44;
249;
251;
Порывшись в RFC, легко убедиться, что добрая половина протоколов не нужна не только рабочим станциям, но и серверам, а многие из них даже не имеют собственного имени, ограничиваясь только номером. В частности, протоколы 43 и 44 отвечают за маршрутизацию и фрагментацию в IPv6. Причем, в ранних бетах посылка мусора по 43 протоколу вводила Висту в глубокую задумчивость, граничащую с суицидом, но через некоторое время она все-таки возвращалась к обработке сетевых запросов, как ни в чем не бывало. А вот мусор, переданный по 44 протоколу, обрушивал систему в голубой экран смерти. Сейчас это уже исправлено, но неизвестно, сколько еще ошибок реализации предстоит узнать.

Алгоритм сборки IP-пакетов изменился в худшую сторону и частично перекрывающиеся пакеты теперь безжалостно отбраковываются как неверные, порочные и вообще недостойные для существования (на самом деле, программистам лень было топтать клавиатуру, вот они и "срезали углы"). Исключение составляет ситуация, когда два пакета перекрываются на 100%, тогда отбрасывается последний пакет в пользу первого, хотя LINUX-системы поступают с точностью до наоборот. Вообще же говоря, проблем со сборкой перекрывающихся пакетов у всех систем хватает и каждая из них имеет свои особенности, в результате чего принятые данные искажаются или пакет не собирается вообще! Рисунок, приведенный ниже, показывает порядок сборки UDP пакета, состоящего из нескольких перекрывающихся фрагментов. Как видно, Виста оказывается далеко не на высоте.

Новые TCP/UDP порты
Нормальный клиентский узел вообще не должен содержать никаких открытых TCP/UDP портов! Он даже может не обрабатывать ICMP-сообщения, в частности - игноровать echo-запросы (на чем основан ping) и не отправлять уведомлений о "казни" пакета с "просроченным" TTL (на чем основана работа утилиты tracert), хотя все это считается дурным тоном и создает больше проблем, чем их решает.

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

Вот неполный список портов, открываемых системой в конфигурации по умолчанию:

IPv6 UDP
MS-RPC (135)
NTP (123)
SMB (445)
ISAKMP (500)
UPnP (1900)
Web Services Discovery (3702)
Windows Collaboration (54745)
совместный доступ к файлам и принтерам (137, 138)
порты-призраки: (49767, 62133)
IPv4 UDP
Teredo (4380, 61587)
MS-RPC (135)
SMB (445)
NBT (139)
PNRP 3540
IPv4 TCP
P2P Grouping Meetings (3587)
Windows Collaboration (54744)
совместный доступ к файлам и принтерам (137, 138)
Изобилие открытых портов подогревает хакерский интерес и создает серьезную угрозу безопасности. Только наивный может верить в то, что все эти сервисы реализованы без ошибок, тем более, что ошибки уже начинают выползать. Как видно, IPv6 отображает часть UDP-портов на IPv4, однако забывает "объяснить" этот факт своему же собственному брандмауэру и если мы закрываем печально известный 135-порт на IPv4, его необходимо закрыть также и на IPv6, равно как и наоборот.

В ранних бетах факт закрытия портов было очень легко обнаружить, поскольку при попытке установки соединения с несуществующим портом система возвращала пакет с флагом RST (как, собственно, и положено делать по RFC). Соответственно, порты, не возвратившие пакета с таким флагом, но и не установившие соединения, все-таки существуют, но закрыты брандмауэром, который можно легко обойти, например, через RPC. Правда, эта лазейка была быстро закрыта, но зато при отправке сообщения на несуществующий UDP IPv6 порт до сих пор возвращается ICMPv6 сообщение об ошибке, опять-таки позволяющее отличить отсутствующие порты от портов, закрытых брандмауэром.

linux# nmap -P0 -sT -p1-65535 10.200.200.127
PORT STATE SERVICE
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
49152/tcp filtered unknown
49153/tcp filtered unknown
49154/tcp filtered unknown
49155/tcp filtered unknown
49156/tcp filtered unknown
49157/tcp filtered unknown

Листинг 1. Успешное сканирование портов, закрытых встроенным в Висту брандмауэром.

Протокол, обеспечивающий совместный доступ к файлам и принтерам - SMB, также полностью переписан и представлен в инаугурации новой версии - SMB2, ориентированной на передачу больших файлов данных и как будто бы обеспечивающий лучшую производительность, однако реализованный далеко не самым лучшим образом. В частности, засылка мусора в порт 445 обрушивала бету build 5270 в голубой экран смерти и была исправлена только в следующей версии.

Механизмы аутентификации, вызывающие множество нареканий еще со времен 9x, похоже не претерпели никаких радикальных изменений, откатившись назад в мрачную готическую тьму средневековья, когда нестандартные клиенты типа SAMBA предоставляли доступ ко многим защищенным ресурсам не требуя авторизации. Помнится, реакция Microsoft была такова: "SAMBA - это неправильный клиент, пользуйтесь штатными средствами Windows и у вас не будет никаких проблем". Похоже, парни из Рейдмонда не понимают, чем клиент отличается от сервера и до сих пор не въезжают в тему. А может, просто трава такая попалась. Термоядерная. Уж всяко не местная, подзаборная. Иначе чем можно объяснить тот факт, что протокол SMB держит для своих внутренних целей именованный канал (по-английски - pipe) "IPC$", через который можно подключаться к ресурсам netlogon, lsarpc и samr без аутентификации! В SMB2 этот список пополнился: "protected_storage" и "lsass", что легко проверить с помощью скрипта trypipes.py, входящего в состав знаменитого хакерского набора dcerpc: