Подробные замечания по книге "Атака из Интернет" — Архив WASM.RU

Крис Касперски
kpnc@aport.ru
12 марта 2001

Мефистофель: "Я знаю много, хоть не всеведущ я"
И.В. Гете "Фауст"

Disclaimer

  Все, сказанное ниже, является моим частным мнением при рассмотрении которого необходимо учитывать: а) отсутствие у меня образования и какой бы там ни было научной степени; б) отсутствие опыта работы с сетями и мои поверхностные дилетантские знания; в) невозможность проверки всех, описываемых в книге экспериментов, выкладок и данных в силу отсутствия доступа к необходимому оборудованию\ПО. Наибольшие пробелы приходятся на Java и межсетевые экраны, поэтому, проверить соответствующие главы я не могу, во всяком случае, с подобающим качеством.
  Помимо указаний на явные ошибки (описки, неточности), местами, я рискую высказывать свое мнение, базирующиеся на осмыслении непроверенной информации из других изданий и источников. Я допускаю, что в моих суждениях могут быть встречные ошибки, однако, всеми силами стремлюсь свести их вероятность к минимуму.
  Все, высказанное мной, прошу считать адресованным некоторому абстрактному лицу, именуемому автором, под которым ни в коем случае не подразумевается Илья Медведовский и все остальные члены писательской группы.
  Илья мне друг, а техническое редактирование к дружбе не относится. Если местами мои замечания покажутся грубы или излишне резки - заранее приношу свои извинения - писал в спешке, со всеми отсюда вытекающими.

Издание третье, переработанное и дополненное

  В сравнении со вторым изданием, третье дополнилось семьюдесятью новыми страницами (не считая главы, посвященной основам Perl - т.к. она не соответствует тематике книги и новых покупателей не добавит), таким образом, обновление составило всего 15% от общего объема книги, причем 60% последнего издания книги взяты из первого издания!
  Переработка материала сохранившегося от первого и вторых изданий полностью отсутствует - автор не только не берет на себя труд добавить материал, касающийся новых систем и исправления описываемых им "дырок", но даже не корректирует такие обороты, как "недавно", "существует дырка", которые в новом издании следовало бы исправить на "давным-давно", "существовала такая-то дырка, но была давно исправлена" и т.д.
  Многие из проблем, затронутых автором, в настоящее время успешно решены и издание книги в не переработанном виде может вызвать резко негативную реакцию читателей, более того, она дезинформирует их, создавая неверное представление о текущем положении дел в области безопасности.
  Поэтому, ее издание авторитета издательства не улучшит, а вот наоборот - очень может быть, особенно если учесть огромное количество содержащихся в ней ошибок, чаще всего неисправимые даже капитальным редактированием. Тот факт, что большинство из них до сих пор не были никем замечены (или были мало кем замечены) еще ни о чем не говорит. Ошибки в третьем издании необходимо обязательно ликвидировать! Тем более, что книга претендует на роль учебной литературы, рекомендуемой автором для студентов и аспирантов.

Общие замечания по книге:

  1) материал книги чрезвычайно устарел, большая ее часть относится к Windows NT 4.0, Windows 95, и Linux 1.2.8. С подавляющим большинством описанных атак разработчики справились еще в 1998-1999 годах, и для читателя, работающего Windows 98, Windows 2000, Windows Me и Linux 2.x, книга уже не актуальна. Автор никак не отразил ни устранение старых "дырок", ни появление новых. Для книги, делающий акцент на частных случаях, а не на концептуальных уязвимостях (а именно таковой и является настоящая книга, вопреки заверениям ее автора), такой подход категорически неприемлем.
  2) книга не дает практических советов администратору и частному пользователю, ожидающего ответов на вопросы вроде "какие версии ПО уязвимы?", "как настроить подсистему безопасности ПО и ОС?", "какие сервисы относительно безопасны, а от каких следует отказаться?" и т.д. Автор склонен к завуалированным обобщениям в стиле "поставить и соответственно сконфигурировать FireWall", "модифицировать ядро" но умалчивает как конкретно это сделать.
  3) книга очень плохо структурирована - много повторов как в рамках всей книги, так и в пределах одной главы. Изложение непоследовательно, мысли "скачут блохой", из-за этого трудно уследить за нитью разговора. Стиль от главы к главе очень контрастный: от академического, перегруженного излишними формулами и сокращениями, до свободного жаргонно-разговорного. Большинство глав являются законченной вещью в себе, и по всей видимости, представляют собой статьи или лекции, помещенные в книгу без подобающей обработки и стыковки со всем остальным материалом (это действительно статьи, многие из которых можно обнаружить в журналах "Открытые системы", "LAN" и др., а так же на это указывают описки "в данной статье", не исправленные на "в данной главе (книге)").
  4) особо необходимо отметить небрежность автора в обращении с технической документацией - вместо того, чтобы в нее заглянуть, он часто предается умозаключениям (по обыкновению неверным). Причем, речь идет не о мало кому известных тонкостях, а о базовых понятиях, большей частью включенных в курсы подготовки сертифицированных специалистов Microsoft, и по идее знакомых каждому администратору, а уж тем более эксперту по безопасности.
  5) значительная часть книги посвящена внутрисегментным локальным атакам, в то время как заголовок гласит "Атака из Интернет", т.е. возникает несоответствие между заглавием и содержанием.
  6) раздражает постоянная "распальцовка" автора. Он издевательски высказывается о Microsoft, о разработчиках Интернет - протоколов и т.д. в стиле дураки все кругом! Между тем, наезды автора очень часто не имеют под собой никакой почвы и связаны либо с непониманием почему такое-то реализовано так, а не иначе, либо с неумением устранить такую-то проблему. Мало того, что читателю не интересны эмоции автора, так эти эмоции местами по детски наивны.
  7) автор намеренно создает у читателя неверное представление о защищенности Интернет и проблемах безопасности, чрезвычайно раздувая атаки, в настоящее время принципиально неспособные нанести какой-либо ущерб, даже эфемерный. При этом, вместо конкретных советов он предается панике, а для решения проблем отсылает к экспертам по безопасности и фирмам, работающих в этой области. Книга - не рекламный проспект, за нее читатель платит деньги, и ожидает получить должную отдачу. Мысль обратится за помощью к кому-либо придет в его голову и без этого.
  8) материал книги в своей массе построен на общедоступной информации, наличествующей в Интернет и в распространенной литературе. Какой-либо новизны книга в себе не несет.

Вывод

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

Перечь ошибок и замечаний

"Стоит только предположить, будто в речах определенного человека заключена абсолютная истина, как тут же появляется когорта специалистов по истолкованию его речей. А так как специалисты эти держат в своих руках ключ к истине, то они неминуемо приобретают власть, которой пользуются, как и всякая другая привилегированная каста, ради собственной выгоды."   Бертран Рассел "Внесла ли религия полезный вклад в цивилизацию?"

Легенда:

  Замечания разделены по главам, из-за путаницы с нумерацией некоторые главы мной ошибочно объединены в одну.
  Знак диез, стоящий после названия главы, обозначает издание в котором эта глава впервые появилась, а число, следующее после запятой - количество страниц в этой главе. Если после названия главы ничего не указано, то эта глава впервые появилась в первом издании.

  Структура комментариев следующая:
  СтепеньОшибки "ЦИТАТА" НОМЕР СТРАНИЦЫ\nКОММЕНТАРИЙ

  "Степень ошибки" может принимать значения "!,!!!,+,+++ и ???", их расшифровка приведена ниже:

• Знаком "!" отмечены грубые технические ошибки, а знаком "!!!" - очень грубые.
• Знаком "+" отмечены неточности, а знаком "+++" - серьезные неточности
• Знаком "???" отмечены непонятные редактору, т.е. мне места

  Цитата (иногда с сокращениями) указывает на комментируемый текст. Страница указывает на местонахождение цитаты и может принимать значение "там же", если цитата находится на той же странице, что и предыдущая Для удобства отслеживания страниц они выделены жирным шрифтом.
  Внимание: если ошибка распространяется на остальной текст, то он как правило не комментируется.

Предисловие, Хакеры и кракеры

  Общие замечания по главе: очень много воды, беллетристики, эмоций, частных мнений автора, много цифр, взятых неизвестно откуда. Рассуждения о хакерах очень поверхностны, какой-либо анализ отсутствует, (сравни с Дж. Вейнцбаум "возможности ЭВМ и человеческий разум").

  +"Неординарность подхода состоит в том, что в его основу составляет анализ алгоритмических и технических особенностей реализации Интернет, используемых нарушителями Сети" стр. 4
  Во-первых, такой подход не нов, и на неординарность претендовать не может, во-вторых, автор, вопреки своим утверждениям, не приводит подобного анализа и не сообщает необходимых технических подробностей для понимания происходящего. Например, глава посвященная безопасности WEB-серверов, - простое перечисление дырок, без объяснений их причин.

  ! "значение механизмов атак позволяет в большинстве случаев предотвратить их путем правильного администрирования" там же
  Нет, неверно. Большинство атак (см. например рассылку security.nnov.ru) базируются на ошибках программной реализации ОС и серверного ПО, которые не устранимы никаким администрированием, независимо от того, понимает ли администратор суть происходящего или нет. А наложение заплаток, выпущенных производителем, осмысления их работы не требует.

  +"В последние год-два книжные прилавки стали заполнятся всевозможными книгами и журналами, в названии которых присутствует слово "Интернет" стр. 7
  Обновить!

  +"В книге рассматриваются практически все угрозы..." там же
  Сильное утверждение, но неверное.

  !!!"просматривая большое количество статей... о проблемах компьютерного взлома, нельзя не обратить внимание на тот факт, что ни в одной статье не проводится та грань, которая, по нашему мнению, четко разделяет всех, так или иначе связанных с компьютерной безопасностью". стр. 9
  Во-первых, "ни в одной" - откровенно ложное утверждение, напротив, на эту тему все пофилософствовать рады (например, Эрик Раймонд, Безруков, Мирза Бабаев, очень много материла содержится на сайте MIT).
  Во-вторых, разделение на черных и белых невозможно в принципе, т.к. апеллирует к закону и морали, а они варьируются от стране к стране и меняются со временем. Если фирма MS запрещает дизассемблировать ее продукцию, то данное действие независимо от целей им преследуемых незаконно (при условии, что закон данной страны солидарен с MS), даже если совершено экспертом по безопасности для предотвращения вселенской угрозы.

  !!! "вандалы... самая малочисленная часть кракеров" стр. 11
  Напротив, самая многочисленная и огромное количество простейших вирусов и атак, совершаемых грубой силой, не требующей ума, или эксплоитами - тому подтверждение.

  + "мы не утверждаем, что критические вычислительные системы не уязвимы, практически невозможно лишь реализовать на них успешную удаленную атаку" стр. 14
  Добавить "через Инетрет", т.к. дальше автор к удаленным причислит и внутрисегментные атаки, против которых уязвимы и "критические" вычислительные системы.

  !!!"практически все современные атаки базируются на слабостях, существовавших в системе безопасности семейства протоколов TCP/IP... уже двадцать лет назад" стр. 17
  Очень спорное утверждение. Стоит ли тогда считать такие атаки современными? А насчет недостатков IPv6 - как раз детища современности, автор даже не упоминает, хотя его проблемы отличны от проблем своих предшественников - а их проблемы как раз в своей массе и разрешены.

  + "Россия - защищайтесь!" стр. 22
  Убрать - подобные девизы не уместны в технич. литературе.

  + "Все приведенные выше примеры..." стр. 35
  Где примеры-то? Нет там ничего...

Социальная инженерия и ее применение (#2, 20)

  Общие замечания по главе: изложение поверхностно, автор рассказывает о вещах и без того известных и очевидных, а серьезный психологический анализ, - отсутствует.

Удаленные атаки на РВС

  Общие замечания по главе: очень много повторов и пересечений с главой "Основные понятия компьютерной безопасности"; язык главы очень тяжелый, перегруженный формулами и неинтересный массовому читателю; предложенная автором классификация атак неверна, в частности, в ней не определено место атакам, основанным на подлоге - очевидно, что они не относятся ни к нарушениям конфиденциальности, ни к нарушениям целостности, ни к нарушениям работоспособности - т.е. ни к одному из пунктов классификации автора.

  !"основная цель практически всех атак - получить несанкционированный доступ к информации" стр. 46
  В Интернете, где подавляющее большинство информации общедоступно, на первое место выходят DoS-атаки, блокирующие доступ к ресурсу. Несанкционированный доступ более характерен для Интранет-сетей.

  !"...нарушение конфиденциальности информации, является пассивным воздействием" там же
  Неверно, похищение информации может потребовать (и часто требует) активных действий со стороны злоумышленника!

  !"Особенностью протоколов FTP и TELNET является то, что пароли и идентификаторы пользователей передаются по сети в открытом, незашифрованном виде" стр. 70
  Неверно! Тот же telnet клиент из штатной поставки Windows 2000 поддерживает схему аутентификации "запрос-отклик", которая при условии правильной реализации принципиально не чувствительна к перехвату трафика.

  !"...необходимы и достаточным условием для условием для получения доступа к хостам по протоколам FTP и TELNET является имя и пароль пользователя" там же
  Неверно! Еще может контролироваться и IP-адрес хоста - с некоторых адресов (особенно внешних или proxy) могут просто не пустить! Причем, в отношении FTP такая проверка может осуществляется средствами самого FTP-протокола!

  !"TELNET разбивает пароль на символы и пересылает из по одному, помещая каждый символ пароля в соответствующий пакет" там же
  Неверно! Не учтен алгоритм Нагла, - до получения TCP-подтверждения все остальные Telnet-пакеты накапливаются на передающем узле и объединяются в один, который и посылается после получения подтверждения, так же следует учитывать режим работы терминала - возможна передача всего пароля в одном пакете.

"Ложный ARP сервер в сети Интернет"

  Общие замечания по главе: значимость атаки "ложный ARP-сервер", приводящей к перехвату трафика, весьма раздута - в Ethernet-сетях трафик можно слушать и так без всех этих замороченк. Поэтому, ARP-атака ничего не дает, за исключением возможности выдать себя за другого субъекта (да и то с ограничениями). Вот об этом и следует писать, а все остальное я бы на месте автора убрал.
  Содержимое главы очень плохо структурировано - много возвратов, повторов, крайне непоследовательное изложение. Много путаницы с понятиями "ARP-таблица" и "ARP-кэш" - за терминологией надо следить (хотя это по сути одно и то же, но все-таки)!
  Почему совсем ничего не сказано о RARP? Об этом обязательно необходимо сказать! Ложный сервер RARP это намного коварнее ложного сервера ARP!
  Попутно - имеет ли смысл помещать эту главу в книгу, посвященную атакам на Интернет? Ведь описанная атака применима только к локальным сетям, да и то при условии, что злоумышленник находится в одном сегменте с жертвой. Удаленная, т.е. из Интернет, ARP-атака невозможна, независимо от того, подключена ли локальная сеть к Интернет или нет.

  + "для адресации IP-пакетов в сети Internet... необходим еще либо Ethernet-адрес его сетевого адаптера..." стр. 72
  заменить "Internet" на "Ethernet", а "его сетевого адаптера" на "сетевого адаптера целевого узла"

  +++"авторы столкнулись с тем, что зачастую даже очень квалифицированные сетевые администраторы и программисты не знают, либо не понимают тонкостей работы протокола ARP" стр. 74
  Вот те и раз!!! И это несмотря на то, что в экзаменационных билетах сертифицированного специалиста Майрософт уйма вопросов как раз и относится к ARP, а в сопутствующей литературе он развернуто описан, равно как и в любой книге, посвященный TCP\IP, причем зачастую много подробнее, чем настоящим автором. А в Windows входит утилита для изменения таблиц ARP, которая описана в хелпе... Администратора, не знающего базовых понятий протокола ARP (а никакие "тонкости" для подмены сервера и не требуются, хотя бы уже потому, что сам автор употребил неверный термин - ложный не ARP-сервер, а ARP-модуль если уж говорить о тонкостях), не то что "очень квалифицированным", а просто "администратором" язык назвать не поворачивается, це - функционер, занимающий не свое место.

  + "в котором указывает IP адрес маршрутизатора..." стр. 73
  добавить "свой Ethernet и IP адрес", иначе непонятно какую информацию заносит маршрутизатор в свою таблицу.

  +"выдать команду сетевой ОС на установку нового IP адреса, потом обратится в сеть - сразу же будет послан широковещательный ARP-запрос, и маршрутизатор, получив этот запрос, автоматически обновит запись в своей ARP-таблице" стр. 74
  Слишком туманно. "Обратится в сеть" - это как? Если послать пакет на хост, находящийся в пределах прямой видимости, маршрутизатор - отдыхает, ну а если ему самому, таки да.
  Если автор хочет сказать, что ОС при смене IP самостоятельно уведомляет об этом маршрутизатор - так пусть прямо и говорит, но уведомлением занимается не любая ОС и не всегда делает это по умолчанию.

  ! "обладатель данного IP потеряет связь с внешним миром" там же
  При первой же попытке отправить пакет за пределы локального сегмента, он тут же нарвется на маршрутизатор, который вновь обновит свой кэш и вновь все заработает.

  ! "некоторые ОС анализируют все передаваемые по сети широковещательные ARP-запросы" там же
  Ну широковещательные анализируют они все, иначе как же сеть будет функционировать? А для изменения кэша марштутизатора ему злоумышленник пошлет запрос, направленный ему персонально. При условии, конечно, что он уже знает его аппаратный адрес. Т.е. хакер должен для верности сначала послать пакет во внешний мир, потом сменить свой IP, потом вновь послать пакет во внешний мир.

  ! "поисковый ARP-запрос" стр. 75
  заменить "поисковый" на "широковещательный"

  +"(например, Windows 95, SunOS)" там же
  А что относительно Windows NT\Windows 98\Windows Me?

  +"Другой, значительно более предпочтительный способ: послать ARP-запрос, указав в качестве своего IP-адреса любой свободный в данном сегменте IP-адрес" cтр. 76
  И чем это предпочтительнее? Это просто легальная смена IP вот и все и никакой опасности она не представляет, разве что скрывает IP атакующего и частично его маскирует...

  !!! "Видимо, программисты Microsoft считали, что маршрутизатор может менять свой Ethernet-адрес?!" там же
  Я предлагаю всем скинуться и купить Медведовскому RFC - стандарты бывает нелишне иной раз перед сном почитать. Да, да, маршрутизатор может и меняет свой Ethernet-адрес, если его сетевуха скинет лапти. И разработчики ARP-протокола это предусмотрели, заставив обновлять ARP-кэш периодическими запросами. Парни из Microsoft тут не причем - они просто реализовали стандарт вот и все. А вот что они не реализовали - так это грех не знать, (хотя MS это признает открыто, даже акцентирует внимание), что записи в ARP кэше уничтожаются спустя 10 минут после занесения независимо от того было ли обращение или нет. А эта "тонкость" играет роль для описанной атаки, но автор о ней - ни гу-гу!

  !"...причина успеха данной удаленной атаки кроется не столько в Internet, сколько в широковещательной среде Ethernet" там же
  Каким же макаром эта атака осуществима через Интернет? Вероятно, автор хотел сказать вместо "Internet "- "ARP протокол" (эта же ошибка повторяется и на странице 77)
  Во-вторых, с этого и надо было начинать главу - в широковещательной среде Ethernet и кроется причина успешности данной атаки, слабости ARP-протокола тут не при чем.

Ложный DNS-сервер в сети Internet

  Общие замечания по главе: DNS-атаки, описываемые в главе, - больше теоретическая, нежели практическая угроза, во всяком случае теперь, когда все исправлено. Автор стоит свои рассуждения на множестве допущений, кроме того не рассказывает о нововведениях, предпринятых на устранение этой и без того небольшой угрозы.

  + "хост посылает на IP-адрес ближайшего DNS-сервера (он устанавливается при настойке сетевой ОС)" стр. 78
  В настоящее время никаких "ручных" настоек делать не требуется - при входе в сеть они определяются автоматически. А в Windows NT 4.0 была дырка (частично устраненная в Windows 2000), позволяющая злоумышленнику изменить адрес DNS, указанный в настойках ОС.

  ! "В случае, если DNS сервер не обнаружил в своей базе имен, указанное в запросе имя, DNS-запрос отсылается сервером на один из корневых DNS-серверов..." там же
  Это частный случай! Ответ DNS может содержать либо требуемую информацию, либо ссылку на другой сервер, либо ошибку (не рекурсивный способ). При рекурсивном способе в ответе всегда возвращается либо требуемая информация, либо ошибка - но никогда ссылка на другой DNS. Такое обстоятельство существенно для понимания атаки, особенно для "подминания" самого DNS.

  + "необходимо обратить внимание на следующие тонкости в работе этой службы" стр. 79
  А тонкости-то где? Далее описываются как всегда базовые понятия...

  !"по умолчанию служба DNS функционирует на базе протокола UDP" там же
  Это дезинформация! Служба DNS функционирует на двух протоколах - TCP и UDP, первый ей необходим для передачи откликов, размер который превышает максимальный размер дейтограммы. Другой вопрос, что по умолчанию отклик ожидается по тому протоколу, по какому был послал запрос. В локальных сетях это по умолчанию UDP, а в глобальных рекомендуется по соображениям быстродействия переходить на TCP, ибо увеличатся процент потерянных пакетов, повторных запросов т.д.

  +"...протокол UDP... вообще не предусматривает идентификации сообщений" там же
  Но ее предусматривает сам протокол DNS и в современных реализациях достаточно хорошо предусматривает!

  !"для того, чтобы перейти от UDP к TCP, администратору DNS-сервера придется очень серьезно изучить документацию (в стандартной документации на демон Named в OC Linux нет никакого упоминания о возможном выборе протокола" там же
  "Перейти" от UDP к TCP невозможно - т.к. всегда поддерживаются оба протокола. Вот генерировать отклик с взведенным TC флагом на UDP-запрос можно - для указания клиенту принять ответ по TCP (можно и UDP запретить, но тогда придется конфигурировать и клиентов). И это описано в куче литературы, в том числе и майкрософтовской, а отсутствие этой информации в Linux только доказывает, что ее разработчики спустя рукава относятся к документации и сопровождению.

  !"конечная сетевая ОС вначале посылает DNS-запрос с использованием протокола UDP" там же
  Что значит "конечная"? Многие ОС семейства UNIX ведут себя не так, а Windows 2000 допускает запрет UDP и это, кстати, рекомендуется при ее использовании в глобальных сетях, именно по причинам, описанным выше.

  +"и только в том случае, если ей придет специальный ответ от DNS-сервера, сетевая ОС пошлет DNS-запрос с использованием TCP" там же
  Этот "специальный" ответ - отклик с установленным битом TC, который сигнализирует о том, что размер отклика превысил максимальный размер UDP-дейтограммы. см. RFC 1035

  !"значение поля "порт отправителя" в UDP-пакете вначале принимает значение >1023 и увеличивается с каждым переданным DNS-запросом" там же
  Сейчас проверил в Windows 2000 - это не так! В других операционных системах лично не проверял, но по сообщению Константина Пьязина, и там это давно исправлено.

  !"1. Ожидание DNS-запроса.... 4...." стр. 80
  К тому времени, пока атакующей сформирует и пошлет жертве подложный пакет, она уже успеет получить ответ от настоящего DNS и проигнорирует пакет злоумышленника. Необходимо дополнительное условие - злоумышленник должен исхитриться перехватить, проанализировать и послать подложный пакет быстрее, чем жертва получит настоящий. Это накладывает серьезные ограничения на атаку.

  !!!"особый смысл в этих действиях трудно найти - зачем каждый раз передавать на FTP-сервер IP адрес клиента?" стр. 81
  Х!, FTP-клиент может попросить FTP-сервер передать файл на другой узел, а не только самому клиенту (!) для чего и сообщает его (или свой) IP-адрес. Стандарты читать будем? Это же в любой книжке по FTP описано! см. RFC-959

  !"Самое интересное - этот пакет будет воспринят как нормальный пакет..." там же
  Не вижу ничего интересного. И почему автор называет их (пакеты) в единственном числе? По меньшей мере их будет четыре - столько и нужно для установки нового TCP-соединения и начала обмена данными. FTP-протокол обычно работает с установкой двух TCP-соединений - одно для передачи команд, другое для передачи данных. А поскольку создастся новое соединение, нет причин удивляться что посланный "пакет" воспринимается "нормальным" см. RFC-959

  !"...номер порта-отправителя принимает ограниченный набор значений (>1023)" стр. 82
  Неверно! По крайней мере под Windows 2000. повтор, это уже говорилось на стр. 79

  !"... он (ID -KK) либо равен единице..." там же
  Неверно! Это было уже старо и не актуально даже на момент первого издания книги "Атака через Интернет" см. Q167629 "Predictable Query IDs Pose Security Risks for DNS Servers" о 9 Июня 1997 (!) года .

  !"Все! Атака состоялась,..." там же
  Не так быстро! Прикинем вероятность ее успеха. Даже если найти клиента, который генерирует при запросах предсказуемые порты и ID, так, что бы всего потребовалось послать не более десяти тысяч пакетов (т.е. определение ID и port с феноменальный точностью до 100), один из которых совпадает с истинным (такая ситуация действительно когда-то имела место в Windows 95), то вероятность, что такой пакет попадает жертве раньше ответа DNS сервера зависит от пропускной способности канала и скорости ответа DNS-сервера. При межсегментных атаках практически не реально доставлять жертве более 100 пакетов в секунду (грубо - каждый DNS ответ - 100 байт, тогда 100 пакетов - 10 килобайт - почти полная загрузка канала на 128 килобит\сек), еще не считая того, что часть из них может быть потеряна, то выходит, что даже на передачу 10000 пакетов придется затратить 100 секунд, а на загруженных каналах и того больше! Пусть легальный DNS отвечает через секунду (а практически - это происходит еще быстрее), тогда в лучшем случае (ну просто в идеальных условиях для злоумышленника) один шанс из ста, что атака удастся. А если принять, что DNS отвечает за 1/10 секунды, то шансы хакера упадут до 0,1% - и это только в Windows 95, но не NT в которой генерируется действительно случайный 16-битный ID и вероятность успешной атаки неотличима от нуля.
  Словом, значимость этой атаки непомерно раздута...

  +"и угрожает безопасности любого хоста Internet, использующего обычную службу DNS" стр. 83.
  Так уж и любого? Во-первых, вероятность успешной атаки даже под Windows 95 близка к одному из тысячи, и равна нулю под Windows NT. Во-вторых, у жертвы может быть локальный DNS-кэш и она не будет каждый раз обращаться к DNS-серверу (понятно, что кэш надо периодически обновлять - и рано или поздно такие обращения будут, но они окажутся очень редки). Третье - корпоративного клиента (а мы про каких говорим? Не про Васей же Пупкиных) так просто не взять - система обнаружения вторжения (а они у него есть) такой UDP-шторм просто не пропустит, к тому же в локальной сети все клиенты, как правило, обращаются к своему DNS, а фире-валл (в правильной конфигурации) вообще не пропустит никакие UDP-пакеты, присланные из вне. Словом - очень много упрощений для столь сильного слова как "любого". Не так уж велика опасность, исходящая от DNS, гораздо вероятнее цунами в Сахаре. Нет, вообще-то описанная атака осуществима (и у меня есть опыт ее практической реализации), но для этого приходится прибегать к дополнительным ухищрениям, о которых автор ни слова не сказал, и которые напрямую не связаны с уязвимостью DNS.

  +"если DNS-сервер не обнаружил в своей базе имен указанное в запросе имя, то запрос отсылается на один из корневых DNS" там же
  или возвращается сообщение об ошибке, или указание клиенту самостоятельно обратиться к серверу, который лучше осведомлен в этом вопросе, но это уже повтор стр. 78

  +"... запрос отсылается на один из корневых DNS, адреса которых содержатся в файле настоек сервера root.cache" там же
  Не всегда, - это зависит от реализации, и вообще излишняя никому не нужная подробность. В DNS-сервере от MS, эта информация содержится в папке %Systemroot%\System32\DNS, а конкретнее в файле Cache.dns, о котором знает каждый амин. см. Article ID: Q176975 от 8 декабря 1997.

  !!! "...ничто не мешает атакующему,... перенести свой удар непосредственно на DNS-сервер" там же
  Если бы! Во-первых, DNS, расположенный в локальной сети, - а именно его требуется атаковать в большинстве случаев, защищен различными МЭС, и будет очень здорово, если хакеру хотя бы удастся определить его адрес (хотелось бы мне узнать- как!).
  Во-вторых, сами DNS с друг - другом зачастую общаются по TCP, во всяком случае при обращении к серверам верхнего уровня, т.к. при использовании UDP велик процент потерь пакетов и накладные расходы на создание постоянного TCP-соединения обходится дешевле.
  В-третьих, в этом случае невозможно угадать ID, т.к. даже если используется реализация, увеличивающая его с каждым запросом на единицу, невозможно узнать (даже приблизительно) сколько запросов послал сервер с начала своей работы.
  В-четвертых, ответы на большинство запросов уже находятся в кэше, и никакого запроса не происходит.
  В-пятых, настоящий DNS верхнего уровня скорее всего ответит атакуемому серверу раньше, чем атакующий подберет правильный пакет. После чего информация окажется занесенной в кэш, который очень не скоро обновиться.
  Фух... далее - по моим собственным экспериментам - существует не так много DNS серверов, которые описанным способом можно атаковать - это скорее редкое исключение чем правило.
  Кстати, если на то пошло, почему автор не советует блокировать DOS атакой сервер верхнего уровня и не объясняет как злоумышленник может узнать его адрес?

  !!! "с течением времени эта ложная информация,... будет распространяться на соседние DNS-серверы высших уровней" стр. 84
  С чего вдруг? Не проще ли в этом случае было бы поставить у злоумышленника собственный DNS и, манипулируя им, воздействовать на сервера высших уровней? На самом деле, следует сказать, низших...

  ! "ничто не мешает атакующему... спровоцировать DNS-сервер на поиск указанного в запросе имени" там же
  Встречный вопрос - если в кэше DNS искомого имени до сих пор нет, то не означает ли это, что его никто не запрашивал и маловероятно что бы запросил в обозримом будущем? Какой смысл имеет такая атака? Конечно, если открылся новый сайт, и хакер тут же подменил его адрес на свой, в ожидании первых посетителей, то да, - это сработает. Но не слишком ли большая натяжка? Вероятнее всего, хакера кто-то уже опередил и требуемый адрес уже занесен в кэш.

  + "видимо, большинство российских кракеров еще не доросли до столь утонченных методов взлома, как атака на DNS" стр. 85
  Зачем такие длинные пальцы? Лучше будет, если сказать это помягче. А насчет утонченности - не надо ля-ля, это атака грубой силой и перебором. Кстати, очень неэффективная, поэтому, и не использующаяся. В той же популярной в определенных кругах "Максиум Секьюрити - хакерс руководств по защите сети" говорится, что DNS атаки не практичны и редко приводят к ожидаемому результату, словом, помимо их есть масса других более подходящих способов, коими каркеры и пользуются.

  +++ "для примера вспомним недавний скандал (28 октября 1996 года)" там же
  Ничего себе "недавний"

  +"Высокая квалификация необходима именно для поиска той самой уязвимости..." там же.
  Искать дыры - много ума не надо. Хватит простого знания английского для чтения документации... Понятно, что дыра дыре рознь, вот это и надо сказать, но описанные дыры слишком очевидны и к таковым не относятся.

  !"позволяет атакующему организовать удаленную атаку на любой хост... и может пробить серьезную брешь в безопасности". стр. 86
  Во-первых, это повтор. Во-вторых, атака на DNS на практике при своей реализации встречает много трудностей - см. мои комментарии выше. Ну не стоит бросаться такими громкими словами.

"Навязывание хосту ложного маршрута с использованием протокола ICMP"

  Общие замечания по главе: глава большей частью относится к внутрисегментным Ethernet-атакам, как, впрочем, как и две предыдущие главы то же. Может, следует назвать книгу "Внутрисегментные атаки из Ethernet?" Где Интернет-атаки?!
  Нет ни слова о новом протоколе ICMPv6 его проблемах и появившихся улучшениях (см. RFC-1885).
  Не упоминаются многие уязвимости ICMP протокола, например, возможность навязать хосту ложное время, да и вообще если от имени жертвы направить ICMP ECHO на множество узлов, то они закидают ее ICMP ответами и она ляжет. Потом, с помощью того же ICMP можно заставить жертву снизить скорость соединения.
  Всего это автор не упоминает, а приводимая им реализация межсегментной атаки позволяет всего на всего однократно разорвать соединение жертвы с некоторым узлом, да и то если известен его IP адрес. Ну и какая от этого жертве печаль? ftp клиенты поддерживают докачку (ну, как правило, поддерживают), почтовые клиенты не держат подолгу соединение, для WEB вообще разрыв соединения не проблема - если кнопка обновить, да и загрузка одного элемента странички (не всей странички!) занимает столь короткое время, что атакующий просто не сможет этот момент угадать. Словом, описанная ситуация, опять-таки представляет только академический интерес.

  + "в статье рассматривается..." стр. 87
  В книге.

  !"сообщение Redirect бывает двух видов" стр. 89
  Четырех. см. RFC -792

  !"в этом сообщении указывается IP-адрес хоста, для которого необходима смена маршрута и новый IP-адрес марщрутизатора" там же
  А так же IP-заголовок исходного сообщения и 64 бита данных оригинального IP пакета. (см. RFC-792). Вопрос на засыпку - каким Макаром их сможет угадать злоумышленник?

  !"Необходимо обратить внимание на важное ограничение, накладываемое на IP адрес нового маршрутизатора" там же
  Почему оно (ограничение) в единственном числе? Например, BSD4.4 выполняет следующие проверки перед использованием нового маршрута:
  а) новый маршрутизатор должен быть в непосредственно подключенной сети (вот это автор и упомянул, но забыл все остальное)
  б) перенаправление должно быть от текущего маршрутизатора на указанный пункт назначения
  в) перенаправление не может заставить хост использовать самого себя в качестве аршрутизатора
  г) модифицируемый маршрут должен быть непрямым маршрутом.
  д) в ответе должен содержаться оригинальный IP-заголовок и 64 бита данных
  Windows 2000 выполняет еще больше проверок - перечислять их все было бы муторно, достаточно заглянуть в хелп, а еще лучше - дизасмом в ядро. А удивляться, что маршрутизатор не может быть вне пределов досягаемости сети не приходится, т.к. пакеты нуль транспортироваться не могут

  +"сообщение Redirect dategramm for Network является устаревшим и уже не используется современными сетевыми ОС" там же

  Угу, со времен BSD 4.2 не используется, ибо маршрутизаторы должны посылать только перенаправления к хостам (code 1 или 3), а не перенаправления к сетям, но тут есть свои тонкости - во-первых, некоторые хосты воспринимают принятое перенаправление к сети как перенаправление к хосту, во-вторых, в большинстве ядер UNIX-like OC есть переменная с именем наподобие ip_sendredirects, которая как раз и управляет реакцией на пере направляющее сообщения. Системы 4.4 BSD, SunOS 4.1.x, Solaris 2.x и AIX 3.2.х, по умолчанию ее держат включенной. Так что трудно сказать, что она совсем уж не используется.

  + "Windows NT... Наплевательское отношение разработчиков этих систем к вопросам обеспечения безопасности в данном случае привело..." там же
  А к чему оно, собственно, привело? Что можно сделать, находясь вне сегмента сети? Разорвать соединение с таким-то хостом, да и то с ограничениями?

  + "существует опасность несанкционированного изменения маршрута на хосте" там же
  Очень небольшая, ввиду ограничений, о которых я скажу ниже

  ! "единственным параметром, идентифицирующим это сообщение, является IP-адрес отправителя" там же
  Э, нет! ICMP-сообщение об ошибке, должно включать в себя заголовок и 8 байт данных исходного IP пакета, вызвавшего ошибку. Вовсе не факт, что жертва проверяет в нем только свой IP, порт и протокол! А попробуй-ка угадай значения всех остальных полей! Так что идентификация выполнена достаточно хорошо (во всяком случае по RFC, который читать надо - он рулез).
  RFC 792 "The internet header plus the first 64 bits of the original datagram's data. This data is used by the host to match the message to the appropriate process. If a higher level protocol uses port numbers, they are assumed to be in the first 64 data bits of the original datagram's data."

  !"по схеме Диффии-Хелмана..." там же.
  ??? ICMP уже используется для снятия денег со счета?

  ! "ничто не мешает атакующему самому послать ложное ICMP Redirect сообщение о смене маршрута от имени маршрутизатора" стр. 90
  см. выше.

  ! "в качестве IP-адреса нового маршрутизатора может указать либо свой IP адрес либо любой адрес данной подсети" там же
  Во-первых, послать подобное сообщение можно только ответом на IP-пакет жертвы, направленный на маршрутизатор, а просто так оно в большинстве реализаций будет проигнорировано. Второе - успешность атаки зависит от положения галки "использовать дефлотный шлюз".

  +"если пришел ARP-запрос, то посылается ARP-ответ" там же
  Зачем эти подробности? Ведь ARP-ответ посылает не злоумышленник, а его ОС и ему об этом знать ничего не обязательно, - это совершенно не принципиально для атаки. А вот то, что при посыле на удаленный узел ему передается эмулировать ICMP Echo, который посылается удаленной системе для проверки соединения с ней (см. учебник Microsoft Certified Systems Engineer), автор почему-то пропустил!

  +"В случае осуществления второго варианта удаленной атаки атакующий находится в другом сегменте относительно цели атаки" стр. 91
  Добавить - но на пути трафика, ибо во-первых, как уже говорилось, по стандарту ICMP сообщение об ошибке может придти только на посланный IP-пакет, а не свалиться "с неба", причем сообщение об ошибке должно содержать IP хидер + 64 бита данных. Второе - не факт, что маршрутизатор (или МЭС) пропустят такое сообщение.

  +"нарушится связь между данным хостом и указанным в ложном ICMP-сообщении сервером" там же
  ...после чего ОС (при соответствующей настойке) пошлет сей пакет на дефлотный шлюз... Поэтому, атакующий должен не вносить новую запись в таблицу маршрутизации, а менять адрес шлюза, - вот об этом и надо писать!

  +++ "Остальные ОС,... игнорировали данное ICMP Redirect сообщение" стр. 92
  Не совсем - просто они сверяли 64 бита возращенного IP заголовка, якобы породившего ошибку. Если его подделать, лягут и они (я проверил - работает!)

  +"Другой способ защиты состоит в изменении... ядра операционных систем" там же
  Зачем? Как правило, у них есть специальная переменная-флаг для этой цели (см. выше)

  +"Но это возможно только в случае свободно распространяемых исходных текстов..." там же
  Ну а NT можно вылечить ковырянием в реестре - сейчас навскидку не помню, а копаться лень, но соответствующий ключ там точно есть. А вот, нашел - HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\EnableICMPRedirect

Подмена одного из субъектов TCP-соединения в сети Internet

  Общие замечания по главе: материал главы не плох, но почему же он остается не переработанным со времен первого издания? Не рассказано о возможности вклинивания в уже существующее TCP-соединение, автор не упомянул о механизмах идентификации, появившихся в IPv6...

  + "Именно поэтому протоколы прикладного уровня FTP и TELNET, ... реализованы на базе протокола TCP" стр. 92
  Известны реализации FTP на базе UDP, впрочем, они не получили большого распространения...

  + "...может содержать следующие командные биты" там же
  Не совсем корректно - оно не может, оно и так их содержит, а они могут быть взведены или нет. Почему, кстати, их названия даны без перевода и объяснения?

  + "В отвечает B--> A: SYN, ACK, ISSb, ACK(ISSa+1)" там же и далее
  Зачем два раза дублируется ACK?

  ++ "(а лучше аппаратного)" стр. 95
  Хватит и программного

  !!! "...достаточно послать всего 100000 пакетов" стр. 99
  Нет! Как человек, неоднократно воспроизводивший эту атаку в лаб. условиях (и просто как здравомыслящий человек), должен сказать, что 1000000 пакетов мгновенно переданы быть не могут (не надо объяснять почему?), а за это время идентификаторы сторон изменяться и придется составлять новый список пакетов для рассылки, поэтому, их число увеличится.

  + стр. 104 - 105 так же 106 - 109
  Не лучше ли сократить протокол?

  + "в сети Internet (стандарта IPv4) не предусмотрен контроль за IP адресом отправителя сообщения" стр. 113
  На мой взгляд здесь бы следовало бы рассказать об средствах аутентификации, появившихся в IPv6

  +++ "очевидность данной удаленной атаки была ясна еще лет двадцать назад... корни этой атаки находятся в самой инфрастуктуре сети Internet, в ее базовых протоколах TCP и IP" стр. 113
  Не все так мрачно! Некоторые системы реализуют очередь типа LIFO, а не FIFO, и уже одно это снижает эффективность затопления SYN-ами, особенно, если очередь кольцевая. А в отношении NT - эта зараза виснет (кстати, в для нее были выпущены заплатки и в Windows 2000 это уже исправлено) только потому, что кому-то из руководителей проекта взбрело в голову размещать буфера в неоткачиваемой памяти количество которой ограничено (причем весьма!).
  Т.е. все-таки все козни от кривых реализаций, а не самих протоколов. Причем тут протоколы? И их тем более IP, который вообще никакого соединения не устанавливает - про него и речи не идет...

  + "другая разновидность атаки "Отказ в обслуживании"..." там же
  А не та же ли самая? Правильнее сказать, что если система не ограничивает размер очереди, и размешает ее в неоткачиваемой памяти, то на SYN-штором она отреагирует безоговорочным повисанием, а если огранивает - то при заполнении очереди запросов будет игнорировать все попытки подключения, в т.ч. и от легальных пользователей. Но это не две разновидности одной атаки - это две разновидности реакции на одну и ту же атаку.

  !"передаваемые TCP-запросы направлялись на FTP-порт, .. а так как Windows 95 принципиально клиентская операционная система и FTP-сервера под нее нет, то... сохранять в памяти запросы и дожидаться рукопожатия ей просто не было необходимости". стр. 115
  Во-первых, на странице 114 утверждалось, что целевой порт меняется (кстати, строго говоря, нет понятия FTP-порт, так и следует писать 21 порт, но это мелочь, ладно), а теперь выходит, что шторм пакетов был направлен на FTP-порт. Так он менялся или нет?
  Второе, FTP-серверов под Windows 95 просто уйма, да и причем тут полноценный FTP-сервер? Достаточно, просто открыть соответствующий порт для подключения (пара строк на перле или Си) и Windows как миленькая, будет ставить все запросы в очередь. А так она отвечает на все RST, и говорить о переполнении очереди просто некорректно (поэтому-то и она и "встает" сразу же после снятия воздействия).
  А причина ее "полегания" в вин-мутанте, который не дает ничему выполняется пока обрабатывается одно подключение - но только оно обработалось, система не дает никому управления, т.к. видит, что нужно обрабатывать второе подключение, подоспевшее во время обработки первого, ну и все, собственно - ласты.
  Обязательно следует объяснить, почему, системы ложатся от SYN-шторма, приходящего даже на закрытый порт, причем, что интересно, у разных операционных систем эти причины различны!!! И виноваты в этом не проколы... и не Интернет...

  + "Направленный шторм на OC Win NT 4.0" там же и далее
  Хорошо бы рассказать и о Windows 2000.

  ! " стр. 118.

  Формула неверна, т.к. при вероятность определяется одним лишь отношением , где U - количество пакетов, генерируемых пользователем. Физическая аналогия - час пик при отсутствии электричек. Вероятность уехать равна не частоте следования электричек, а отношению мест в электричке (размеру очереди) к количеству людей (пакетов).
  Дело в том, что если очередь заполнена, очередной пакет уничтожается. Но рано или поздно появляется "окно", готовое принять свежий пакет. Вероятность обойти злоумышленника зависит только от соотношения количества пересылаемых им и юзером пакетов, но ни от размера очереди (при чем тут размер - когда она уже вся забита?!), ни от значения тайм-аута она не зависит.
  Попутно - а зачем эта формула?! Все, выведенные с ее помощью цифры, не выдерживают экспериментальной проверки, особенно, это хорошо заметно на больших тайм-аутах - формула безбожно занижает вероятность!

  + "80й HHTP-порт на сервере одновременно позволяет создавать не боле 80 соединений с удаленными почтовыми серверами" стр. 119
  Почтовыми-то причем? Ничего не понял. Чем мерялось-то это? Заходы браузера или просто TCP соединение?

  ! "опцию, позволяющую установить неомраченное максимальное число одновременно подключенных клиентов. Однако, на уровне TCP это число все равно ограничено приведенными выше значениями... Microsoft просто поражает" там же
  Это неправда! На уровне драйвера TCPIP число соединений не ограничено, а вот у AFD, лежащим уровнем выше, - таки да. Поэтому, чтобы увеличить макТСРконнекшен надо смотреть не настойки TCPIP, а AFD.
  Второе - "Клиент" != "соединение", это понятия разные и настраиваются в различных местах.

  + "не более примерно 1040 соединений..." там же
  1000 по дефлоту, 40.000 максиум. Доки читать когда будем?

  + "139 порт... "родной" для NT порт..." там же
  От такой же для не родной, как 23, телнетовский например. SMB протокол разрабатывался для OS/2, без участия команды разработчиков Win NT.

  !!! "параметр N изменить в данной версии невозможно" стр. 120
  Это неправда! См. "HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\ Services\ AFD\ Parameters \EnableDynamicBacklog".

  !!! "Обычный Microsoft NetTech Knoweledge Base не содержит даже этой информации (!!!)" там же
  Да ну? А если поискать? (Кстати. слово Knowledge написано с ошибкой). А как же техническая статья за номером Q142641 "Internet Server Unavailable Because of Malicious SYN Attacks" от 8 января 1998 года? Очень познавательная статья, кстати, неплохо бы прочесть!

  !!! "WWW, FTP, SMTP, POP3 серверы на базе Windows NT 4.0 Server функционировать не будут! Любой кракер с обычным модемом на 33600 сможет...." там же
  Не верно! Windows NT поддерживает динамическое увеличение очереди по мере возникновения в ней потребности. Это каждый администратор знает. Да и в той же NT 4.0 MS уже приняла меры защиты, про Win 2000 я и вовсе молчу. Словом, заявление автора - смешно (или наивно).

  +"..умиляет привилегированность родного 139 порта - более чем двенадцатикратный приоритет... особенно это интересно смотрится вкупе с невозможность ручного изменения длинны очереди на определенном порту" там же
  Ну дык, - сперва там было то ли 7 то ли 11 мак. конекшен, а потом, когда поняли что этого мало - взяли с запасом. А насчет "ручного" изменения длины очереди - см. настойки ADF и TCP - там это есть (ключ реестра выше).

  ! "любой кракер с обычным модемом на 33600 бит.сек сможет генерировать "шторм" запросов порядка 80 зап\сек..." там же
  Это экспериментальные данные или прикидка? Если считать, не забывая учесть подзаголовок TCP/IP, то выходит 56 пакетов максимум.

  + "в существующем стандарте сети Internet IPv4 нет приемлемых способов надежно обезопасить свои системы от этой удаленной атаки" стр. 121
  Проделам простой подсчет. Пусть хакер в секунду направляет 20.000 пакетов (100% загрузка 10 Мегабитовой сети)... для обработки одного подключения требуется байт 100 памяти (NT требует 78 байт). Тогда за секунду будет вылетать ~ 2 мегабайта. Возьмем тайм-аут секунд 30 (мало не будет), тогда максимальный расход памяти составит 60, ну пускай 100 мегабайт. По современным понятиям - тьфу, не так много, чтобы говорить о принципиальной незащищенности, тем паче, что не обязательно требовать физическую память - сгодится на худой конец и виртуальная...
  Дело не в протоколах, дело в том, что пропуская способность канала обгоняет аппаратные возможности некоторых серверов. Теоретически и без атаки может сложиться указанная ситуация.

  + максимальный размер дейтаграммы... в среде ATM 56 байт" там же
  Цитирую RFC-791: "Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets"

  !!! "значение в поле смещения указывается в восьмерках байт, и даже если установить это значение в единицу и предположить, что сетевая ОС не проверяет наложение фрагментов, то после сборки фрагментов наложение произойдет только после восьми первых байт TCP или UDP заголовка" стр. 124
  Я не понял, мы RFC читаем перед сном или нет? Согласен насчет UDP, но только не TCP!!! Автор забыл про pseudo-header (превдозаголовк), располагающийся между заголовками IP и TCP, длина которого равна 12 октетам , следовательно, смещение в 8 октетов затирает вторую половину псевдозаголовка и "наезжает" на заголовок TCP. Это описано в RFC-793, т.е. RFC, посвященному самому TCP протоколу, и вовсе не вынесено в какие-то дополнения! Таким образом, описанная атака, отнюдь не миф, а реальность!
  Вот цитата из RFC - "This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. This gives the TCP protection against misrouted segments. This information is carried in the Internet Protocol and is transferred across the TCP/Network interface in the arguments or results of calls by the TCP on the IP.

Код (Text):

1.  
2. +--------+--------+--------+--------+
3. |           Source Address          |
4. +--------+--------+--------+--------+
5. |         Destination Address       |
6. +--------+--------+--------+--------+
7. |  zero  |  PTCL  |    TCP Length   |
8. +--------+--------+--------+--------+"
9.  

  !!! "как нам кажется, сама идея наложения фрагментов достаточно любопытна. Другое дело, что применение ее для проникновения пакетов атакующего через FireWall в существующем IPv4 представляется маловероятным" там же
  Даже если не существует TCP-подзаголовка, все равно можно обойти FireWell, - например, пусть он фильтрует пакеты с установленным битом срочности на 139 порт - так наложением фрагментов, можно изменить TCP пакет "взводя" бит срочности только после сборки. Еще так можно обойти МСЭ, реагирующих на SYN атаку или предотвращающих нестандартные приемы сканирования и т.д....

  + "мы начали тестирование и.. абсолютно не удивились, когда ни одна из исследуемых операционных систем.. не реагировали" стр. 127
  "Microsoft has confirmed this to be a problem in Windows NT version 3.51..." см. Article ID: Q132470. Если уж Майкрософт признала...

Атаки, использующие ошибки реализации сетевых служб (#2,4)

  Общие замечания по главе: слишком коротко и не актуально уже для Windows 98, - про новые операционные системы, как водится, ни слова нет.

  + "LAND" стр. 129
  Очень длинное, многословное и запутанное описание атаки, при этот так и не раскрывающее ее деталей. Критикуемая автором Microsoft с этой задачей справляется на порядок лучше и на два порядка лаконичнее. см. Q165005 "This behavior occurs because of "Land Attack." Land Attack sends SYN packets with the same source and destination IP addresses and the same source and destination ports to a host computer. This makes it appear as if the host computer sent the packet to itself. Windows NT operates more slowly while the host computer tries to respond to itself."

  + "эксперименты авторов показали, что этой уязвимости подвержены все версии ОС... правильно Windows NT/Windows 95" там же
  Это неправда! Не следует делать умозаключений на счет "всех" - вполне достаточно если авторы перечислят уязвимые версии, над которыми они экспериментировали

  ! "...при установленном Service Pack 3" там же
  А он должен спасть? см. Q165005 "This hotfix was originally posted on November 26, 1997. A subsequent fix was completed on January 9, 1998 to address another nearly identical attack and this hotfix has replaced the original one. The original hotfix is included in Windows NT 4.0 Service Pack 3. The most recent hotfix is not; however, it is available from the following Internet locations"

  ! "причем Service Pack 4.0 спасает в этом случае несильно... при тестировании "направленным штормом" Land-запросов Windows NT 4.0 на платформе Pentium 200 с установленным Service Pack 4 (серьезно улучшена реакция NT на атаку Land), порог нормальной работы в случае шторма не более 3500 зап\сек" там же
  Не понятно - так защищает SP 4 или нет? Автор противоречит сам себе в пределах одного абзаца. Второе - такое количество запросов уже не проходит через канал 128 килобит и требует по крайней мере 256 - кило битного, очень плотно его забивая, что само по себе уже затрудняет доступ к машине. Атака Land тут не при чем - это просто нехватка ресурсов для работы. Точно так вела бы себя система и при обработке обычных пакетов. Вся прелесть атаки Land, что многие системы (макОс, БеОс, Юниксы) ложаться от одного Land пакета, который может быть отправлен хоть с модема, хоть из Soft-Ice

  ! "end=offset+total_len_)-ihl" стр. 130
  Лишняя скобка, не объяснено что есть что (есть offset - смещение из заголовка, то оно измеряется в восьмерках октетов и его нужно умножить на 8, а если оно уже умножено почему об этом нет упоминания; если ihl - это Internet Header Length, то он измеряется в словах по 32 бита, и его нужно множить на четыре) и вообще RFC-791 записывает процедуру поиска положения в очереди так: "begin = FragmentOffset*8; end =(TotalLength-(HeaderLength*4))+FragmentOffset*8"

  + "IF (prev!=NULL &&..." там же
  Это на каком языке? Почему "IF" на заглавном регистре, нет точек с запятой в конце строки?

  + "копирование блока отрицательной длины вызывает выход компьютера из строя" стр. 131
  В самом деле?

  + "Пакеты посылаются с любого адреса на любой из портов, независимо, открыт он или нет" там же
  Это IP-атака! А в IP пакете нет поля "порт"!

  ! "...newtear... другая вариация на тему этой атаки bonk" там же
  А что, между ними есть какие-то различия помимо названий? Одно и ту же атаку Майрософтовцы называют "newtear", а все остальные "bonk" (bonking) см. "Cryptic Controls" в "crypto/scope" от January 15, 1998; "Norvin LeachMSDN Online News Editor "At Microsoft, we call it NewTear, since it's a variant of the Teardrop attack. On the Internet, however, it's called Bonk. And, given the meaning of the term "bonking" in Britain (I'll let you guess at that), there's quite a bit of funny mail flowing around. It may not be as memorable as the Ping of Death, but it's close."

  + "на открытый (обычно, 139-й) TCP-порт" стр. 132
  Не обычно, а на 139 именно - а атака известна под именем WinNuke

Методы удаленного сканирования портов (#2, 14)

  Общие замечания по главе: много технических описок, небрежность в использовании терминологии, отсутствие информации по новым приемам сканирования, преувеличены возможности описанных способов "невидимого" сканирования, не описано сканирование UDP-портов (автор ошибочно полагает, что они ничем не отличается от TCP-сканирования).

  !!! "UDP-сканирование принципиально ничем не отличается..." стр. 133
  Неправда! UDP-протокол не располагает средствами контроля доставки и установки связи. см. RFC-768. Но при попадании дейтаграммы на неоткрытый UDP порт, генерируется ICMP-сообщение о недоступности порта. Так что тут все не так, как в TCP!

  +++ "далее приводится текст файла /etc/services из ОС Linux" там же
  Следует ли тратить 5 страниц текста на заведомо доступный, очень неполный и морально устаревший список, да еще с непереведенными комментарии (вернее, практически без комментариев вовсе), тем более что дальше в главе он даже не упоминается.Это что, просто для объема?

  +++ "рассмотрим чуть более подробно процесс подключения к серверному приложению, ожидающего запросов на подключение на каком-либо TCP-порту" стр. 137
  Повтор! Оно намного более подробно уже рассматривалось на странице 92

  !!! "если же ответ через определенный интервал времени так и не пришел..." там же
  ...значит кто-то выдернул из машины сетевой кабель При попытке установить TCP-соединение с закрытым портом, принимающая сторона посылает TCP-RST.

  +++ "метод "невидимого" анонимного сканирования. Непосредственный инициатор сканирования в принципе не определяется объектом сканирования" стр. 138
  Если на то пошло, то можно просто подключится телнетом к удаленной машине и оттуда набрать telnet адрес целевого хоста порт (или подключится через несколько промежуточных машин). Жертва принципиально не сможет опередить кто ее так. Правда, спецслужбы потенциально могут, - стоит им поднять логи сервера. Любопытно, что все анонимные методы, описанные автором, - на самом деле не анонимны, т.к. на прямую общаются со вспомогательным узлом.
  Т.е. и в том и в ином случае идет цепочка Хакер -> хост -> жертва. Какая тут анонимность? Жертва знает адрес хоста, а хост - адрес Хакера. Полностью анонимны только схемы пассивного сканирования, когда хакер не передает ни на вспомогательный хост, ни на жертву никаких пакетов, содержащих его обратный адрес. А их очень немного и все они достаточно сложны и непрактичны...

  !!! "TCP SYN-сканирование: очевидный метод, основанный на принципах создания TCP-соединения и состоящий в последовательной передачи на объект сканирования TCP SYN запросов на соединение..." там же
  Не правда! TCP-SYN сканирование основано на диаметрально противоположном - идея, лежащая в его основе состоит в том, что если хост отвечает SYN ACK (порт открыт), то сканирующий не посылает в свою очередь ACK! Соединение остается не закрытым и вскоре вышивается по тайм-ауту. Достоинства метода в том, что его труднее обнаружить - многие МСЭ не считают это сканированием вообще.
  Напротив, "очевидное" сканирование состоит в полной установке соединения и элементарно обнаруживается. Автор описал не тот метод. Это даже в nethack.faq описано - ума не приложу как это до сих пор никто не заметил?!

  ! "TCP FIN-сканирование: данный метод основан на некоторых тонкостях реализации протокола TCP в различных ОС" стр. 139
  Это ошибка? Нет, это системная функция! Никакие это не особенности, а ошибка, особенно характерная для BSD и некоторых других систем. Стандарт (RFC-793) говорит по этому поводу следующее: "As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case". Именно так должна вести себя любая система по стандарту и здравому смыслу. Не стоит слишком вольно трактовать следующие строки RFC - "If an unsolicited FIN arrives from the network, the receiving TCP can ACK it and tell the user that the connection is closing." т.к. они внутренне противоречивы и приводят к неоднозначности. Листая RFC можно обнаружить множество статей, предлагающий слать тинграммы в одном TCP пакете, со взведенными FIN, ACK и SYN или вариации на эту тему. Предлагалось слишком много вариаций, что должен делать узел, получивший FIN, не предваренный подтвержденным SYN. Но все это не по стандарту, поэтому...

  ! "на передаваемый объект сканирования TCP FIN-запрос закрытые порты отвечают пакетом с флагом RST, а открытые игнорируют данный запрос. Однако, сетевые ОС фирмы Microsoft не подвержены такому методу сканирования" там же.
  Во-первых, не запрос, а уведомление об одностороннем закрытии соединения, которого никто и не думал устанавливать.
  Во-вторых такое сканирование осуществляется со взведенными ASK и FIN флагами, и существуют вариации SYN+FIN, ASK+SYN+FIN и т.д.
  Располагает ли автор сведениям как каждая из ОС от MS реагирует на эти комбинации? Вполне вероятно, что ее поведение будет отлично от приема пакета с одним лишь FIN-ом.

  ??? "Сканирование с использованием IP фрагментации" там же
  Непонятно, какие это дает преимущества? Разве что затрудняет обнаружение сканирования на сетевом уровне...

  + "(от 1000 до 65535)" стр. 140
  от 1.

  !!! "протокол FTP (RFC 959) имеет ряд, чрезвычайно интересных и мало описанных функций, одной из которых является возможность создания так называемых proxy ftp соединений с ftp-сервера" там же
  Эта возможность широко описана в различной литературе! Но на использование ftp-сервера для сканирования портов наложено множество ограничений. Во-первых, команда PORT, передающаяся серверу, требует, чтобы порт был представлен в виде двух аргументов - HIGH и LOW, так чтобы port = HIGH*256+LOW, причем HIGH не может равняться нулю (это не запрещает стандарт, но во всех, видимых мной реализациях это так - если какой сервер и не проверяет HIGH на нуль, то он относится к редкостной экзотике).
  Отсюда - очевидная невозможность сканирования первых 256 портов, которые как раз и представляют основной интерес. Второе, многие реализации Ftp-серверов не позволяют устанавливать соединения на зарезервированные порты, список которых как раз и берется из файла типа /etc/service.
  В-третьих, не каждый сервис может быть готов принять данные, например, дайтайим только передает их и разрывает соединение (см. ниже). Поэтому, использование ftp-сервера для сканирования портов представляется глубоко утопичным и не имеющим никакого практического значения!

  + "в том случае, если программная реализация ftp-сервера поддерживает режим proxy" там же
  А, что она может его не поддерживать? Как же тогда сервер будет соединятся с самим клиентом? Другой вопрос, что сервер может выполнять некоторые дополнительные проверки перед соединением.

  + "на любой другой сервер в Internet" стр. 141
  Необязательно сервер - им может быть и клиентская машина, как в подавляющем большинстве случаев и бывает.

  + "создать процесс DTP-Server" там же
  Не процесс, а модуль! И не создать, - клиент не может создать модуль на сервере, - технически правильно говорить "дождаться пока модуль DTP-Server (которым может являться и клиент, т.к. именно он определяет кто из них будет активом, а кто пассивом) установит соединение с узлом указанным клиентом на указанный порт".

  + "Функциональность данной возможности протокола FTP вызывает некоторое сомнение" там же
  Ну и зря - эта возможность очень удобна для посылки файла другому человеку, без приаттачивания его к письму и без необходимости гонять его сначала к свой машине, потом на сервер, потом от сервера получателю - тройное сокращение трафика!

  ! "подобную возможность, которая теперь выглядит... отнюдь не безопасной" там же
  Абсолютно безопасной, т.к. получатель должен сам предпринять кое-какие шаги для получения данных от сервера (как минимум, открыть порт и приступить к его прослушиванию). И кроме того сам сервер на целевой объект налагает множество ограничений. см. ниже.

  ! "следует выполнить команду LIST, по которой ftp сервер пытается прочитать текущую директорию на объекте сканирования" там же
  С чего вдруг? Таак, открываем RFC на который автор ссылался парой абзацев выше и читаем "LIST: This command causes a list to be sentM from the server to the passive DTP. If the pathname specifies a directory or other" Честно говоря, упорное нежелание автора открыть документацию на которую сам же и ссылается начинает раздражать.

  ! "на ftp-сервер приходит ответ TCP SYN ACK и мы получим от ftp-сервера ответы: 150 226" там же
  Ну, 226 мы получим только после завершения передачи данных клиенту, но не факт, что любой открытый порт готов принять данные. Пример - дайтайм ничего не принимает, а только отдает, хотя его порт и открыт. И потом, код завершения 226 к установлению соединения никакого отношения не имеет, его лучше не упоминать совсем. А если и упоминать, то добавить и 200 - на PORT комманд сукфесл.

  ! "Существует возможность узнать количество пакетов, переданных хостом, по параметру ID в заголовке IP (С каждым переданным пакетом значение ID в заголовке IP-пакета обычно увеличивается на 1" стр. 142
  Весьма спорное утверждение, исходящее из выполнения одного из замечаний в RFC-791 "However, since the Identifier field allows 65,536 different values, some host may be able to simply use unique identifiers independent of destination", но многие реализации обеспечивают уникальность ID лишь одного отправителя, поэтому, его изменение позволяет установить сколько пакетов было отправлено именно этому хосту. Тем более, что RFC никак не говорит каким образом следует обеспечивать уникальность, - если у автора данные какие именно реализации увеличивают его на единицу?

  + "Хост отвечает TCP RST на TCP SYN ACK и ничего не отвечает на TCP RST (Естественно, это происходит только в случае "неожиданного" прихода таких пакетов") там же
  Что значит неожиданных? Не проще ли (и технически грамотнее!) сказать - если "не находится не в состоянии синхронизации"

  + "Если мы пошлем на С несколько TCP SYN..." там же
  А один SYN, что, маловато будет? В чем смысл посылки нескольких пакетов? При условии, что хост действительно "немой" - это ни к чему. Если хост изредка посылает или принимает какие-то пакеты, (а так, обычно, и бывает), то для того, что бы отличить действительно открытый порт от шума, надо слать эти пакеты с некоторым интервалом, а не один за одним, как описывает автор, т.к. это более надежно позволит отождествить интересующие хакера пакеты ото всех посторонних.

  ! "Во-первых, можно воспользоваться анонимными telnet account, коих в Интернет в достатке" стр. 145
  "В достатке" это сколько? Десять? Сто? Тысяча? Стоп, вот тысячи уже и не наберем! Далее - подавляющее большинство из них запрещают устанавливать соединения по нелокальным адресам. Да мало того, если кто и разрешает такую операцию, то во-первых запоминает IP сканирующего, а во-вторых, ставит системы, распознающие сканирование и автоматом прибивающие такой аккаунт (пример - WepProvider.com). Несколько легче найти узел, дающий web-хостинг с Перлом, но и тут проблемы в использовании его для сканирования - за этим следят! Поэтому, предложенный автор метод близко к утопическому.

  + "обнаружена бдительным администратором "в погонах"... и мы долго получали гневные письма с угрозами скорой хакерской расправы с нашими хостами... Но личто нам было очень весело читать подобные гневные письма и объяснять, что если бы у нас был хоть какой-то злой умысел (хотя откуда ему взяться), то уж наверное мы бы сделали так, чтобы нас было невозможно вычислить" стр. 146
  Очень смелое заявление, однако, неправильное. При условии, что протоколы подключений ко всем серверам, используемыми авторами для атаки ведутся, то обнаружить сканирующего принципиально возможно, тем более человеку "в погонах".

Причины успеха удаленных атак на распределительные вычислительные системы и сеть Internet

  Общие замечания по главе: написанная очень тяжелым, излишне заумным языком, эта глава за маской концептуальных проблем, на самом деле описывает частные ошибки реализации, уже исправленные не сегодняшний день на подавляющем большинстве хоств. И ни слова о том, что многие из описанных им "вселенских" проблем разрешены в IPv6, - о котором он даже не упоминает!

  +++ "при этом основным средством анализа безопасности сетевого взаимодействия объектов распределенной системы будет являться описанный в главе 3 сетевой анализ (анализ сетевого трафика" стр. 148
  Еще раз обращаю внимание на несоответствие названию книги и ее содержимому. Это что "Внутрисегментные атаки Ethernet?" В Интернет слушать чужой трафик - не то же самое, что в локальной сети!

  + "успеха угроз" там же
  успеха реализации угроз

  ! "рассматриваемые ниже причины основываются на базовых принципах построения сетевого взаимодействия объектов распределенной ВС" там же
  Однако, приведенные ниже примеры, основываются на частных ошибках, которые в настоящее время уже исправлены.

  +++ "в этой главе мы разберем только причины успеха угроз, направленных на инфраструктуру и базовые протоколы сети, а не угроз теле коммутационным службам" там же
  Это неправда. Автор рассматривает и неоднократно упоминает прикладные протоколы такие как FTP и TELNET, серьезно акцентирует внимание на ошибки древних реализаций DNS. Это не базовые протоколы.

  ! "отказаться от определенных служб (DNS, например)" там же
  Пристрелить, чтобы не мучалась? А не проще ли исправить ошибки реализации, как это уже и сделано?

  ! "прослушивание канала передачи сообщений... такая атака программного возможна только в том случае, если атакующий находится в сети с физической широковещательной средой передачи данных" там же
  Нет, не только - еще существует возможность активного воздействия на информационный поток или ключевые узлы РВС, ответственные за его транспортировку или выбор адреса назначения.
  Топологи "звезда" не является достаточным условием для защиты от такого вида атак, а, учитывая, что подавляющее большинство атак, нацеленных на перехват, как раз действуют по активной схеме воздействия (именно такие атаки и описывает автор, например, подмена содержимого ARP-кэш), то основная причина лежит не в широковещательности среды, а в ошибках разработки протоколов и их программной реализации.

  "Token Ring не является широковещательной" там же
  Это смотря как посмотреть, но в любом случае эта сеть построена по топологии с общей шиной, со всеми отсюда вытекающими последствиями. см. IEEE 802.5

  + "матрица NxN" стр. 150
  Не сказано, что такое N

  !"в прикладных протоколах FTP, TELNET, POP3 имена и пароли пользователей передаются по сет в виде открытых, незашифрованных" стр. 155
  TELNET-клиент под Windows 2000 передает NTLM хеш вместо пароля, а в POP3 изначально предусмотрена команда APOP, реализующая схему запрос-отклик, принципиально устойчивую к man-in-middle.

  ! "Об удаленных атаках, направленных на эти протоколы" стр. 157
  Атаки, направленные на конкретные реализации указанных протоколов, а в отношении DNS шибко устаревшие на сегодняшний день

  ++ "Поэтому, все пользователи сети Интернет могут быть атакованы в любой момент" там же
  Слишком сильное утверждение, не имеющие под собой никакой основы.

Безопасные распределенные вычислительные системы

  Общие замечания по главе: слишком устаревшая, об IPv6, снимающего большинство поставленных в этой главе проблем, автор лишь однократно упоминает, сообщая, что он якобы все еще разрабатывается... Вывод - главу не спасет даже капитальное редактирование - ее следовало бы переписать полностью

  ! "система с выделенными каналами связи - это система, в которой отсутствует неопределенность с информацией о ее объектах. Каждый объект в такой системе изначально однозначно идентифицируется и обладает полной информацией о других объектах системы" стр. 161
  Это неверно! Хорошо, пусть к компьютеру автора подсоединен 1 млрд. (нет, 1 мало - пускай 1 миллиард миллиардов) проводов, связывающих его напрямую со всеми хостами мира. Вопрос, как в этом случае найти хост фирмы Microsoft? На каком он кабеле? Следовательно, необходимо создание специализированной поисковой системы, например, связывающей имена и аппаратные адреса. А, как утверждал выше автор, это несет в себе потенциальную угрозу, т.е. он противоречит сам себе.

  ! "ограниченное число объектов системы (зависит от числа входа у коммутатора)" там же
  Какие физические фундаментальные ограничения мешают увеличить число входов коммутатора?

  !!! "группы разработчиков уже заканчивают проект создания нового, более защищенного стандарта сети Интернет IPv6" стр. 170
  Интересно, автор читал свою книгу перед переизданием?

Как защититься от удаленных атак в сети Internet?

  Общие замечания по главе: глава носит философский характер, и практические рекомендации по защите по типу "руководство к действию" в ней отсутствуют. Содержимое морально устарело и не соответствует действительности. Автор намеренно дезинформирует непрофессионального читателя, создавая у него впечатление полной незащищенности Интернет.

  !"99% процентов информационных ресурсов в сети являются общедоступными" стр. 171
  Во-первых, дважды употреблен символ и слово проценты, во вторых - на сегодняшний день в сети даже не половина, а гораздо меньше ресурсов предполагает свободный доступ, не говоря о корпоративных сетях, подцепленных к Интернет, не говоря о магазинах и проч., достаточно заметить, что большинство FTP-серверов, требуют пароля, как и большинство тел-нет серверов, не говоря уже о почте и т.д.

  !"удаленный доступ к системе в принципе невозможен" там же
  Это неправда! В принципе, возможно получить удаленный доступ посылкой одного IP пакета (который система обязана принять, будь она серверная или клиентская) - достаточно существование всего лишь одной программной ошибки, приводящей, скажем, к срыву стека. Поэтому, следует сказать "при условии отсутствия ошибок реализации". Но захочет ли автор поручится, что в Windows 95\98 таких ошибок нет?

  +"давно известна программа, при некоторых условиях предоставляющая атакующему доступ к файловой системе Windows NT" стр. 172
  Что за программа? Что за условия? Что за файловая система? Что подразумевается под "предоставлением доступа"?

  ! "служба DNS: удобно, но опасно" там же
  Уже давно не так опасно, как то описывает автор

  !!!"Отказ в обслуживании... эта атака используя фундаментальные проблемы в безопасности протоколов и инфраструктуры сети Интернет..." стр. 173
  Это неправда! Причина успешности DOS атак - частные ошибки реализации, и в случае с SYN атакой то же (см. объяснение выше).

  +++ "ОС Windows 95 или Windows NT - наиболее лакомая цель (можно поразить любой хост в сети Интернет, на котором установлена данная ОС)" там же
  Автор тактично умалчивает, что "поражение" сводится к разрыву установленного соединения с другим хостом и атака для своей реализации требует соблюдения множества условий, маловероятных на практике, и уж тем более замалчивается что в современных ОС эта проблема давно решена.

  +++ "самым правильным шагом в этом направлении будет приглашение специалиста по информационной безопасности" там же
  ...который опустошит кошелек клиента и не факт, что сделает, что либо полезное. В частности, наблюдая как автор пытается раздуть значимость каждой безвредной или практически не осуществимой атаки в то же время не упоминая о более серьезных угрозах, поневоле задумываешься о его тактике "промывания мозгов" своим клиентам. Да, пусть не будет это воспринято как личный наезд или упрек, но факт остается фактом, устранять угрозы может тот и только тот, кто лично заинтересован в результатах свое работы, а не получении денег. Очевидно, сторонний эксперт к этой категории не относится.

  !"самым простым решением будет создание... статической ARP-таблицы" стр. 174
  Это неправда! Помимо того, что такое решение добавит много головной боли, оно принципиально не способно защитить от посылки пакетов от чужого имени и анализу трафика.

  ! "использование в сети Internet службы DNS в ее нынешним виде..." там же
  Пояснить, что под "нынешним видом" подразумевается середина 90-х.

  !!! "Как администратору сети защитится от ложного DNS-сервера?" стр. 175
  В этой главе (кстати, она почему-то повторяется два раза) все утверждения ошибочны, чтобы не повторятся, отсылаю к своим комментариям главы "Ложный DNS-сервер".

  +++ "данное сообщение позволяет изменить маршрутизацию Windows 95..." стр. 176
  Но не все последующие версии!

  +++ "Как защитится от отказа в обслуживании" стр. 177
  Автор почему-то рассматривает только одну SYN-атаку, но ничего не говорит о возможности нарушить нормальную работу системы некорректным запросом, .т.е. вообще не затрагивает проблемы ошибок реализации - благодаря которой осуществляется подавляющее большинство атак.

  !!! "что касается базовых протоколов прикладного уровня [длинный перечень протоколов] ни один из них не предусматривает дополнительную защиту соединения..." там же
  Не правда это, впрочем, это очередной повтор... Автор жует все книгу одни и те же ошибочные утверждения

Разновидности межсетевых экранов и шлюзов (#3,10)

  Общие замечания по главе: замечаний нет, никаких ошибок мной не обнаружено, но не факт, что их там нет, т.к мои познания в области МСЭ - очень поверхностные и отрывочные. К сожалению, данная глава не помогла их углубить.

Операционные системы и приложения (#2, +22)

  Общее замечание по главе: крайне непоследовательный и бессистемный материал, - очень сильный акцент на частных случаях, нет четкой классификации атак (предложенная автором классификация неудобна уже тем, что он сам постоянно затрудняется классифицировать с ее помощью описанные атаки).
  Ни слова об архитектуре подсистемы безопасности UNIX и Windows NT, - как разделены процессы и системные ресурсы, как связаны между собой различные кольца защиты, как взаимодействуют между собой различные компоненты ОС и приложений. Автор бегло описывает лишь процедуру авторизации пользователя при входе в систему.
  Не показаны типовые ошибки прикладных программ и компонентов ОС, - приведены лишь примеры очень частных, специфических, сильно устаревших и даже экзотических ошибок, не представляющих никакого интереса, даже исторического, поскольку им посвящено огромное количество материала, циркулирующего по сети.

  ! "изъяны в них являются в большей степени независимым от конкретных реализаций" стр. 191
  Неправда, автор как раз делал упор на ошибки реализаций.

  !!! "Интернет (вернее ее прадед АРПАНЕТ) возникла именно из необходимости связать между собой UNIX компьютеры, которые были самыми распространенными и прогрессивными в то время" там же
  Да что вы такое говорите! Работа над ARPANET началась в конце пятидесятых, когда UNIX еще и в проекте не было. Только в 1965 году начались эксперименты над MULTICS, а UNIX... еще в 1971 году UNIX использовалась лишь в патентом бюро фирмы Bell Labs, а в 1974 UNIX начала использоваться в телефонии внутри компании и только через два года, когда она попала в Беркли, который так же занимался разработкой ARPANET, UNIX стала приобретать черты сетевой системы. Т.е.ARPANET появилось на десять лет раньше! Утверждение, что она возникла из-за необходимости объединить "прогрессивные" UNIX машины - чушь.

  + "Сейчас найти дыру такого рода в демонах очень трудно, но можно" стр. 195
  Достаточно подписаться на любую рассылку по безопасности, чтобы убедится в обратном - дыры сыплются как из рога изобилия.

  + "Стек растет вниз" стр. 204
Общепринято представлять оперативную память в виде списка, с возрастающими индексами, в таком случае, стек растет вверх - т.е. в сторон меньших адресов. Если автор решил использовать обратную схему (в принципе законно, но непривычно), то он должен на это сконцентрировать внимание читателя или еще проще сказать - стек растет в сторону меньших адресов.

  ! "вирус Морриса... дал ответ на давний вопрос, могу ли не в абстрактных условиях существовать само репродуцирующиеся программы" стр. 205
  Вирус Морриса - не первый Интернет червь. Задолго до него существовали "Вьюнок" и "жнец", "Cookie monsters" и толпа прочей нечисти. Вирус Морриса - просто обогнал их в масштабах эпидемии - вот и все...

  ! "почему же по сей день известен только один пример сетевого червя?" там же
  Вот уж, не знаю, почему автор не в курсе насчет остальных (см. замечание выше).

  +++ "разработчики взяли за основу криптостойкий алгоритм DES и на его основе создали функцию crypt" стр. 220
  Не совсем так, - они несколько модернизировали DES, для осложнения аппаратных переборщиков, поэтом, новый алгоритм уже может и не быть криптостойким! Произошло это или нет - другой вопрос.

  ! "выбирается 12-битная случайная привязка (salt)" там же
  Неверно! Привязка представляет собой двухсимвольную последовательность, каждый член которой принадлежит интервалу [A-z] и [0-9], и может принимать 26+26+10 = 62 возможных значения. Таким образом, существует 622=3.844 возможных привязок. Напротив, 12-битовая последовательность дала бы 212 = 4.096 вариаций. 3.844 < 4.096, следовательно, привязка не 12 битовая!

  ! "дающая на выходе 64-битное значение..." там же
  Причем тут конечное значение? Ключ-то 56 битный! Берутся семь младших бит каждого символа исходного восьми символьного пароля - а семью восемь == 56, следовательно для вскрытия необходимо перебрать не 264, а только 254, что намного меньше! (на самом же деле еще меньше, т.к. некоторые символы в паролях запрещены и каждый символ может принимать не 128, а только 94 возможных значения). Поэтому, разрядность "выхода" не дает никакого представления о стойкости пароля. Если уж и выражает ее - так в символах, а не битах!

  !"вызов функции getpwent() иногда позволит получить пароли пользователей в классическом виде" стр. 223
  Что такое "классический вид"? Иногда - это как? Функция getpwent работает только на довольно древних OC аля Юникс и не работает, - вообще никогда, на современных.

  +++"Далее мы рассмотрим типичные атаки... потенциальный кракер все равно найдет их в том же Инернете, а главное, что на сегодняшний день они являются достаточно устаревшими и представляют больше теоретический интерес" стр. 224
  Так стоит ли отписывать очень частные атаки, которые и без того всем известны? Зачем читателю покупать книгу, если содержащийся в ней материал можно найти и бесплатно? Не лучше ли рассмотреть концептуальные атаки, например, типовые ошибки Си-разработчиков?

  + "quote... quote... quote" стр. 226
  Удалить! (Это не вычищенные следы перевода HTML в текст)

  +++ стр. 231 - абракадабра - не правильный шрифт (язык)

  + "RFC-1408 или RFC-1572" стр. 234
  Правильнее сказать вообще-то "и", а еще лучше ссылаться только на самый последний, 1572, RFC.

  +++ "здесь мы приведем две уязвимости в программе SendMail (новых версий), одна из которых позволяет локальному пользователю стать суперпользователем. Вторя уязвимость очень серьезна и в некотором роде даже уникальна... она воздействует на sendmail до одной из последних версий 8.8..." стр. 235
  Почему не описана первая уязвимость? Версия 8.8 не есть одна из самых последних (кстати, какая под-версия имеется автором виду? версии sendmail-а принято задавать в виду трех чисел), т.к. в сети сейчас очень редко удается встретить sendmail младше 8.8.8 (8.8.9), где описанная ошибка устранена.
  В третьих, описанная ошибка ни чем таким не уникальна и даже не любопытна, это все грубые натяжки!

  +++ "...своей масштабностью она прямо может подтолкнуть их к написанию нового глобального червя... любые программы... могут приобретать новые ошибки, в том числе и такие катастрофические" стр. 236
  Глобальный червь был в принципе невозможен в силу малой распространенности указанного МТА данной версии и быстрого реагирования администраторов на ошибки (к тому времени пока полноценный червь был бы написан и отлажен, ему бы не в чем было размножаться) - да и как бы он смог найти адреса машин с установленным sendmail? (сканирование IP не предлагать - долгое это дело).
  Никакого катастрофического характера эта ошибка не носила, нечего людей пугать - и жизнь это подтвердила, - с момент обнаружения ошибки уже прошло несколько лет, - но ничего ужасного так и не произошло...

  + "quote" стр. 237
  Убрать (следы от кривого перевода html -> txt)

  ??? "все версии программы, вплоть до 1.5 оказались уязвимы" стр. 238
  Большинство источников упоминает только версии 1.4-1.5...

  + "переполнением буфера или размеренности массива" стр. 239
  Это в данном контексте одно и то же, незачем повторяться...

  !!! "речь будет идти только об одной (последней на сегодняшний день) версии Windows NT 4.0" стр. 241
  Прошлым летом вышел первый сервис пак к Windows 2000... Какой интерес читать о том, что было в Windows NT 4.0? Хотя бы автор взял на себя труд сравнить обе версии - дабы читатель думал - стоит ли ему переходить с NT на 2000 или нет.

  +++"это единственная система, способная работать на процессорах, отличных от Intel-совместимых, а именно на процессоре Alpha" там же
  Автор забыл о Windows CE! Потом, почему обязательно Alpha? А тот же PowerPC, да и все остальные? (Полный список поддерживаемых процессоров занял бы достаточно много места, поэтому здесь не приводится)

  +++ "Один такой пользователь Guest, по умолчанию имеющий пустой пароль" стр. 244
  В NT он по умолчанию открыт только на рабочей станции, а 2000 вообще отключен.

  +"готовя материал этого пункта мы до самого последнего момента не могли найти хорошего примера...но все же в самый последний момент, в январе 1999..." стр. 246
  Не мешало бы это обновить.

  +++ "В Windows NT... в стандартной конфигурации он [telnet] не предусмотрен" стр. 250
  Но он предусмотрен в Windows 2000!

  +++ "Вообще, использование Windows 95 в качестве основной ОС для хоста (сервера) в Интернете - это нонсенс, и в этой книге такой вариант практически не рассматривается" стр. 251
  Сервера, да, но не хоста, ибо хост - это любой узел, подключенный к Интернету. Существует огромное количество клиентов, сидящих под Windows 9x, имеющих временное или постоянное подключение к Интернет и предоставляющих разделяемые ресурсы. И атака на такие системы - представляет значительный процент ото всех атак вообще!

  +++ "...в каталоге .... существуют поля... означающие имя и пароль пользователя при автоматическом входе в систему" стр. 252
  В 2000 это уже исправлено.

  ! "указание клиенту передать пароль в открытом виде" стр. 254
  Клиент (в 2000 по дефлоту) проигнорирует такой указ, и атака не состоится.

  ! "Windows NT позволит сделать это, даже не спрашивая пользователя о подтверждении - она просто передает имя и хэшированный пароль пользователя на сервер" стр. 256
  Причем тут NT? Это происки клиентского ПО.

  +++ "правда эта атака пассивна - незадачливый клиент сам заходит на враждебный сайт, а не наоборот" там же
  Злоумышленник может послать ему письмо с Java-аплетом, чтобы ускорить развязку

  ! "так как за те же самые 243 операций..." стр. 261
  Нет, на самом деле - 215+(1+k+k2+k3+k4+k5+k6+k7), где k - число символов исходного пароля. Математические выкладки см. http://www.counterpane.com/pptp.html или мою "Технику сетевых атак".

  !"Поставьте последнюю версию (ядра) вашей ОС..." стр. 263
  Последняя - не значит "самая лучшая", напротив, это "темная лошадка", от которой можно ожидать все что угодно, особенно если в нее внесены значительные изменения.

Атака через WWW (#2, 66)

  Общие замечания по главе: традиционно - сильно устаревший материал, в нем правда упоминается IE 5.5, но основной акцент сделан на IE 3.0, древние версии IIS и Apache, такие браузеры, как, например, Opera вообще не упоминаются.
  Материал, посвященный Java я проверить в силу свой полной некомпетентности в этом вопросе не могу. Такое впечатление - что грубых ошибок там по-видимому нет, все выглядит достаточно убедительно, но головы бы на отсечение не дал.

  ??? "...создаем в нем окна размером, например, миллион на миллион пикселей (клавиатура и мышь у клиента будут заблокированы очень скоро" стр. 282
  Windows 2000 такое испытание с достоинством переносит и даже не шибко тормозит. Впрочем, у меня четверть гигабайта RAM, может быть в этом и причина? Но насчет блокировки мыши и клавы даже на меньшем количестве памяти - меня терзают смутные сомнения.

  +++ "while(true)...." стр. 283
  Какой-то неумеренно длинный пример. Нельзя ли покороче? Например: while (true){d = new Date;window.open("xxx", d.getMilliseconds(),"width=1000000,height=10000000,resizable=no");} Это, правда не чистая Java, а JavaScript, но работает она ничуть не хуже, уверяю, зато намного нагляднее!

.NET новое (#3, 1)

  Общие замечания по главе: глава, посвященная новому и интересному направлению, но автор описывает его через чур уж кратно - в общих чертах, не вникая ни в какие детали. Это ближе к обзорной журнальной статье, чем главе книги.
  Ошибок никаких не обнаружено.

Введение в Perl (#3, 20)

  Общие замечания по главе: имеет ли хоть какой-нибудь смысл включение этой главы в книгу, посвященную, Интернет - безопасности, когда на рынке и без того просто море литературы, описывающей Perl. Тем более, что описание автора довольно корявое: слишком поверхностное, непоследованное, абсолютно не структурированное и т.д. Позволю цитату, кстати, "Тогда мы поняли настоящую цену учебникам типа "Язык XXX за двадцать один день" или "YYY - это просто!". Подобные тексты (сами по себе, быть может, и неплохо написанные) оставляют за своими рамками настолько обширные области языка, избегают касаться стольких его тонкостей и особенностей, что в голове у читателя-программиста формируется зачастую усеченный и выхолощенный образ инструмента, который он собирается использовать." Редкая профессия Евгений Зуев

  +++ "русскоязычные издания по языку Perl можно пересчитать по пальцам одной руки" стр. 303
  Неправда, - лично у одного меня русскоязычных книг по Perl более десятка, не считая множество текстов и документации в электронном виде. Может быть, лет пять назад все было иначе, но теперь проблема обратная - что же купить?
  Тем более странно появление этой главы в третьем издании, а не втором, где бы она была гораздо уместнее...

  ! "Perl - программа представляет собой файл, содержащий набор Perl-операторов, и начинающийся со строчки вида #!!usr/bin/perl..." там же
  Во-первых, Perl-программа состоит не только из операторов, во-вторых, абсолютно необязательно начинать таким образом - данная строка всего лишь автоматически запускает интерпретатор Perl при запуске программы, т.к. анализируется ядром UNIX-а, и только им, для Windows NT это вообще не имеет никакого смысла (а Perl портирован и на нее), равно как и оболочек, которые используя ассоциации по расширения, запустят файл, независимо от наличия данной строки. К языку Perl она и вовсе не имеет никакого отношения, т.к. представляет с его точки зрения обычный комментарий.

  ! "UNIX-систем, требующих установки бита исполнения в атрибутах..." там же
  Абсолютно необязательно! Достаточно вызвать скрипт, передав его аргументом командной строки интерпретатору Perl, или перенаправив его на стандартный вход, указав предварительно интерпретатору брать с него текст программы.

  ! "использование директивы use strict" там же
  Неверно, - должно на самом деле быть use strict 'vars'

  ! "скалярные величины.. бывают двух типов - числового и строкового" стр. 304
  Неправда, существуют еще и ссылочные скалярные переменные - итого типов выходит три.

  !!! "для всех чисел используется... внутренне представление - число с плавающей точкой двойной точности" там же
  Это кто сказал? Во-первых, всегда - внутренне представление не должно заботить программиста и оно не постоянно от реализации к реализации, во-вторых, если бы даже это было и так - такая бы реализация языка была бы слишком медленной. В третьих, в языке есть директива use integer предписывающая всегда использовать целочисленную арифметику, даже если и выходит дробная часть, скажем, делим сеть на четыре, - это уже разрушает утверждение автора (см. раздел документации integer - Perl pragma to compute arithmetic in integer instead of double).
  Замечание: в книге много заимствований из Perl Cookbook by Tom Christiansen and Nathan Torkington, во-первых это приводит к дублированию и без того известной информации (Perl cookbook - вещь распространенная в сере программистов), а во-вторых даже в последнем ее издании содержится какое-то количество ошибок, поэтому, принимать все сказанное там на веру без явных ссылок на источник. В частности, утверждение автора о внутреннем формате плавающей арифметике, скорее всего, взято автором оттуда, причем, заимствованно с ошибкой, т.к. в оригинале было "числа обычно хранятся в формате вещественных чисел с двойной точностью", а "обычно" - можно трактовать по-разному, тут в лоб не возразишь. Напротив же, автор заявляет "для всех чисел используется...." Мораль - если воруешь, то делай это с умом

  !"при записи списков вместо операции "," можно воспользоваться =>: ("one",1,"two",2,...)" стр. 306
  Во-первых, не операции, а оператора, во-вторых, дальше автором приведен не список, а хеш-массив.

  + "четные являются индексов, а не четные значением, и начинаются с символа %: %a=(one=>1,)"; там же
  Если говорить чет-нечет, то так и следует писать ...("one",1,"two",2...). И вообще-то нелишне рассказать об обоих способах инициализации хеш-массива.

  +"присвоить его некоторой скалярной переменной...." стр. 307
  "некоторой" опустить - ни к чему оно

  !"{оператор}" стр. 308
  Скорее блок, или любой другой термин, но не оператор, тем более в единственном числе. Perl - не бацик, там не одни операторы!

  + "при наличие директивы use strict" стр. 310
  Должно быть: use strict 'vars'

  +++"разница между ними следующая: my ограничивает область действия переменной текущим блоком, local же делает эту переменную доступной во всех функциях..." там же
  Это утверждение было бы верным, если бы автор не употребил оборот "ограничение" Теперь же он должен сказать, что my ограничивает лексическую область видимости, а local - динамическую. Не принципиально - но за терминологией надо следить.

  ! "а переменные $a и $b, переданные в нее..." там же
  Что-то незаметно, что бы они были в нее переданы.

  +"" там же
  равносильно .

  !"Для вывода файлов, перечисленных в командой строке скрипта используется операция " там же
  Неправда! см. замечание выше

  +++"Для открытия дополнительных дескрипторов..." там же
  Добавить - open(FILE0,"" чтение и запись с очисткой уже существующего файла, "|" - конвейер, "|-" & "-|" - перенаправление и т.д.

  "/^a.*b$/... а директива \b требует" стр. 314
  Тогда так надо и писать /^a.*b\b/

  +"на написать" стр. 315
  не написать

  стр. 321. замечание к листингу
  Не рекомендуется смешивать оператор Безопасность стандартного серверного ПО (#2 )

  Общие замечания по главе: название не соответствует содержимому, в главе ни слова о безопасности - т.е. об принципах устройства и архитектуры защитных механизмов, а всего лишь перечислен ряд произвольно взятых ошибок, в основном касающихся очень древних Apache и IIS, без какой-либо систематизации. Автор классифицирует ошибки в начале главы, но сам этой классификации не следует. Ни слова о новом сервером ПО и концептуальных проблем его безопасности. Единственное исключение - раздел, посвященный созданию безопасных CGI-приложений.

  +++ "Выделим основные классы ошибок" стр. 324
  Такая классификация никуда не годится, т.к. проявления одной и той же ошибки могут быть различными, тем более, что пункт 1 в предложенной автором классификации вытекает из пункта 3, или во всяком случае тесно связан с ним.

  +"Аналогичная ошибка существует в MS Personal Web Server" там же
  Существовала...

  +++ "...указатели. Очевидно, они вышли за пределы разрешенной области..." стр. 327
  Совсем не очевидно! Непонятно - что с чем могла сравнивать операция CMPSB - что в регистрах ESI и EDI? В котором указатель на вводимую клиентом строку или его там и нет совсем? Следовало бы сказать хотя бы из какой функции этот код вызывался...

  + "Недавно обнаруженная ошибка" стр. 328
  Теперь уже - давным-давно

  !"popen" стр. 336
  _popen

  !"у С++... часто можно безболезненно воспользоваться exec и spawn)" стр. 336
  Это функции из C run-tile library.

Проблемы идентификации и аутоидентификации (#3, 15)

  Общие замечания по главе: замечаний нет, единственное пожелание - упросить листинги примеров, сделав их более наглядными, дабы неопытному читателю не приходилось в них разбираться. Все дополнительные проверки, типа проверок на отсутствующий (т.е. пустой) пароль и приведение его к нижнему регистру - лучше убрать - это не суть важно, и ухудшает легкость восприятия листинга

  + "xbnftvj" стр. 361
  Должно быть "читателю"

Методы и средства обнаружения автоматизированных атак(#3,16)

  Общие замечания по главе: мало конкретных примеров, слишком много общих слов, так, например, даже не объясняется таким образом осуществляется анализ инкапсулированных пакетов (при условии, что он осуществляется вообще). Т.е. принцип работы межсетевых экранов дан через чур поверхностно (напротив, автоматизированные средства обнаружения атак в след. главе описаны достаточно подробно), не говоря уже о том, что никакого сравнительного анализа конкретных имеющихся на рынке продуктов в главе не наблюдается - она лишь пересказывает информацию, содержащуюся в любой книге для начинающих администраторов.
  Технических ошибок в главе обнаружено не было (однако, не факт что их там нет - просто у меня отсутствует опыт работы с МЭС и мои познания этой области - поверхностные и сугубо теоретические).

  +"преступлениям?" стр. 368
  убрать знак вопроса

  ! "Поиск нарушителем уязвимости при помощи сканеров безопасности... сам по себе считается атакой" стр. 369
  В начале книги автор дал определение атаки как реализации угрозы, следовательно, поиск уязвимости не является атакой. Необходимо либо изменить определение понятия атаки, либо переформулировать данное утверждение. Тем более, что в главе, посвященной сканированию портов, автор доходчиво объяснил, что сканирование - не атака, а только считается такой по незнанию.

Классификация систем обнаружения атак (#3,22)

  Общие замечания по главе: замечаний нет

  ??? "12. (название главы?)"стр. 385

  Где список литературы, на которую наличествуют ссылки в книге? Приведен только список литературы к одной главе, нумерация в котором отлична от нумерации, принятой в данной книге, - это необходимо исправить и вернуть список на место.
  По причине отсутствия данного списка он не был проверен, равно как не были проверены все ссылки на первоисточники.

Общее впечатление от книги

  Несмотря на значительное количество ошибок, тяжелый язык и устаревший материал, книга в целом оставляет благоприятное впечатление после прочтения, однако, в последнее время на в сети появляется множество конкурирующих изданий, в основном отдельных статей, faq, рассылок обнаруженных дырок, эксплоитов и их описаний. Не дремлет и Microsoft - постоянно совершенствуя свой MSDN - достаточно просто набрать "attack" или "hack" в поле поиска, - ответ будет множество статей и технических заметок, достаточно подробно объясняющих суть такой-то проблемы и способы ее устранения.
  Выдержит ли третье не переработанное издание эту конкуренцию или нет - вот в чем вопрос?

Краткий перечь литературы, использующиеся при подготовке настоящих замечаний

1. MSDN, прилагающееся к Microsoft Visual Studio 6.0
2. документы RFC
3. Литература:
   1. TCP/IP КРУПНЫМ ПЛАНОМ
   2. Albitz, P., and Liu, C. 1992. DNS and BIND. O'Reilly & Associates, Sebastopol, Calif.
   3. Теория и практика программирования на Си в UNIX
   4. Администрирование сети и сервисов internet учебное пособие П. Б. Храмцов
   5. Системы обнаружения атак на сетевом уровне by Robert Graham
   6. Хелен Кастер "Основы Windows NT"
   7. Коробеченко "Недокументированные возможности Windows NT"
   8. Отображение имен NetBIOS в сетях TCP/IP Эрик Холл
   9. BGP протокол by Аlex Rudnev
4. а так же большое количество материала, взятого из Интернет

© Крис Касперски