рекогносцировка на небоскребе

КРИС КАСПЕРСКИ

Спецвыпуск: Хакер, номер #072, стр. 072-058-4

Алгоритм сборки 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);

- NRP 3540;

- IPV4 TCP;

- P2P GROUPING MEETINGS (3587);

- WINDOWS COLLABORATION (54744);

- СОВМЕСТНЫЙ ДОСТУП К ФАЙЛАМ И ПРИНТЕРАМ (137, 138).

Изобилие открытых портов подогревает хакерский интерес и создает серьезную угрозу безопасности. Только наивный может верить в то, что все эти сервисы реализованы без ошибок, тем более что ошибки уже начинают выползать. Как видно, IPv6 отображает часть UDP-портов на IPv4, однако забывает «объяснить» этот факт своему же собственному брандмауэру, и если мы закрываем печально известный 135-й порт на IPv4, его необходимо закрыть так же и на IPv6, равно, как и наоборот.

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