Отказ в обслуживании в Microsoft Windows TCPIP


Сброс WinSock. Переустановка протокола TCP/IP

Иногда эксперименты с настройками сетевых карт, либо вирусы, черви и трояны, или же слишком агрессивные антивирусы повреждают настройки Winsock, что приводит к неадекватной работе сетевых компонентов в системе

Проблема: не работает сеть.

Возможные симптомы:
— Компьютер не получает ip-адрес автоматически. При ручных настройках сеть работает. Служба DHCP-клиент при этом включена.
— Есть пинг по адресам, но нет по именам. Службы DNS-клиент при этом включена.
— Компьютер получает адрес из пространства APIPA (169.254.*.*) практически мгновенно после включения сети, а не после ожидания и таймаута.
— При попытке пинга из командной строки определенного IP-адреса, в ответном сообщении системы после слов «Обмен пакетами с» идут различные непечатные символы, такие как треугольнички, сердечки и т.д.
— Компьютер получает настройки сети не полностью, например получает только адрес шлюза.
— Стартуют и останавливаются большинство сетевых служб.
— Исчезли все созданные сетевые подключения.

Причина:
Такое поведение наблюдается при повреждении разделов реестра, в которых хранится конфигурация Winsock. Что же такое Winsock? Если сказать в «двух словах», то Winsock это интерфейс, который упрощает разработку сетевых приложений под Windows. Всё что нам нужно знать, это то что Winsock представляет собой интерфейс между приложением и транспортным протоколом, выполняющим передачу данных.При взаимодействии клиент — сервер в сети каждого участника взаимодействия можно рассматривать как конечную точку. Сокет это вроде как и есть эта конечная точка. В приложении вы определяете сокет.

Решение:
Нажмите Пуск, в поле Начать поиск введите cmd, щелкните правой кнопкой мыши файл cmd.exe и выберите команду Запуск от имени администратора, а затем нажмите кнопку Продолжить.
Введите в командной строке команду netsh winsock reset и нажмите клавишу Enter. После выполнения команды перезагрузите компьютер.

Для чего нужна команда «netsh winsock reset»?

Winsock используется для обработки данных, передаваемых по протоколу TCP/IP, в процессе которой информация последовательно проходит все установленные на компьютере обработчики этих данных — LSP (Layered Service Provider). Если один из них будет некорректно удален, то цепочка обработки нарушается, и работа по протоколу TCP/IP становится невозможной. Такие ситуации нередко случались, когда в Winsock для перехвата какой-либо информации внедрялось вредоносное приложение. При удалении его антивирусом пользователь лишался сети Интернет, либо был вынужден восстанавливать удаленные вредоносные компоненты. Благодаря автоматическому восстановлению цепочки Winsock необходимость в корректном удалении LSP во многих случаях наконец-то отпала.

Вместе с этим стали доступны две новые команды Netsh:
netsh winsock show catalog — отображение списка установленных на компьютере LSP Winsock.
netsh winsock reset catalog — сброс настроек и восстановление первоначальной конфигурации LSP Winsock

При установке в составе какой-нибудь сборки Windows иногда может некорректно установиться сетевой протокол TCP/IP. В этом случае нужно его переустановить, и по-другому просто никак.

Как это сделать:

1. Запустить regedit и удалить 2 ключа в реестре:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winsock
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WinSock2\

2. В файле Nettcpip.inf (находится в папке windows\inf) найти раздел [MS_TCPIP.PrimaryInstall] и в записи Characteristics = 0xa0 заменить 0xa0 на 0x80.

3. Зайти в Панели управления в Сетевые подключения, правой кнопкой мыши щелкнуть значок Подключение по локальной сети и выбрать Свойства.

4. Открыть вкладку Общие и последовательно щелкнуть Установить, Протокол и Добавить.

5. В окне Выбор сетевых протоколов щелкнуть Установить с диска.

6. В окне Копировать файлы с диска ввести C:\Windows\inf и нажмите кнопку ОК.

7. Выделить пункт Протокол Интернета (TCP/IP) и нажмите кнопку ОК.

8. Вернуться на экран Подключение по локальной сети, но кнопка Удалить теперь активна.

9. Теперь можно удалить Протокол Интернета (TCP/IP).

10. Перезагрузить компьютер.

11. Зайти опять в Сетевые подключения и установить Протокол Интернета (TCP/IP) заново, используя кнопку Установить с диска и путь c:\windows\inf.

Отказ в обслуживании в Microsoft Windows TCP/IP

Доброго времени суток уважаемые форумчяни.
Столкнулся со следующей проблемой, на сервере являющемся контроллером домена возникли проблемы с адресами, у сервера зарезервирован адрес на DHCP сервере и когда я этот адрес прописывал для статики сервак определял домен, но не пинговался не в одну сторону, то есть не другие серверы или рабочие станции его не видели так и сам сервер не видел никого, когда настройки переводил в динамику (то есть в авто определение ip) он появлялся в сети и все было хорошо, но это не правильно и я решил настроить все человечески. Нашел в интернете статью что это ошибка может быть из за каких старых записей в протоколе и на сайте тех поддержки майкрософт рекомендуют очистить кэш или удалить протокола TCP\IP. Попытавшись очистить по данной статьи https://www.it-simple.ru/?p=5674, Увы не получил нужного результата и решил удалять не увидел статью по удалению протокола для windows server 2008r2 и начал делать по данной статье https://support.microsoft.com/kb/325356/ru столкнулся со следующей проблемой в данной инструкции в пункте 11-14 пишут
“Найдите файл Nettcpip.inf в папке %winroot%\inf, затем откройте его с помощью программы «Блокнот».
Найдите раздел [MS_TCPIP.PrimaryInstall].
В записи Characteristics = 0xa0 замените 0xa0 на 0x80.
Сохраните изменения и закройте программу «Блокнот».”

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

Переустановка протокола TCP/IP в Windows 8.1: боремся с ошибкой 720

И ногда, вследствие неосторожных экспериментов с настройками сетевой карты, действия вирусов либо же напротив, слишком агрессивных антивирусов, в Windows происходит сбой, приводящий к невозможности подключения к интернету. При этом пользователь получает ошибку 720 . Также эта ошибка может встречаться при установке «левых» сборок Windows. Наиболее вероятная её причина — сбой настроек сетевого протокола TCP/IP .

Лечится ошибка, хотя и не всегда успешно, переустановкой стека TCP/IP. Процедура эта требует определённого опыта, тем же, кто раньше никогда не сталкивался с указанной ошибкой, советуем внимательно ознакомиться с представленной ниже инструкцией. Но перед тем как приступать к переустановке TCP/IP, для начала стоит попробовать сбросить сетевые настройки к значениям по умолчанию. Для этого в запущенной от имени администратора командной строке следует выполнить три эти команды:

netsh int ipv4 reset reset.log
netsh int ipv6 reset reset.log
netsh winsock reset

Первые две команды сбрасывают настройки протоколов ipv4 и ipv6, третья команда обнуляет настройки протокола Winsock. После этого перезагружаем компьютер и смотрим, исчезла ошибка или нет. Если нет, ничего не поделать, придётся переустанавливать TCP/IP.

Переустановка TCP/IP в Windows 8.1

Открываем редактор реестра, ищем и удаляем эти две ветки:

Оба подраздела (Winsock, Winsock2) должны удаляться без проблем, в отдельных случаях может потребоваться изменения прав доступа. После удаления подразделов перезагружаем компьютер, переходим в системный каталог С:/Windows/inf, находим там файл nettcpip.inf и делаем его резервную копию .

Теперь открываем файл nettcpip.inf любым текстовым редактором и находим следующие строки:

[MS_TCPIP.PrimaryInstall]
; TCPIP has properties to display
Characteristics = 0xA0 ; NCF_HAS_UI | NCF_NOT_USER_REMOVABLE

Заменяем этот участок следующим и сохраняем отредактированный файл:

[MS_TCPIP.PrimaryInstall]
; TCPIP has properties to display
Characteristics = 0x80 ; NCF_HAS_UI

Если при сохранении система выдаст сообщение «Отказано в доступе», сохраните отредактированный nettcpip.inf на рабочий стол, а затем удалив исходный файл с правами администратора, переместите на его место изменённый. После этой процедуры, командой ncpa.cpl открываем «Изменение параметров адаптера», выбираем локальную сеть, открываем её свойства, находим протокол 4 (TCP/IPv4) и жмём кнопку «Установить». При этом откроется маленькое окошко выбора сетевых компонентов.

Выделите в нём пункт «Протокол» и далее Добавить.

Установить с диска.

Обзор и указываем путь к отредактированному файлу nettcpip.inf.

Жмём «OK», в открывшемся окошке выбора протокола выделяем 4 (TCP/IPv4) и опять жмём «OK».

После этих манипуляций для протокола 4 (TCP/IPv4) в окне свойств подключения станет доступна кнопка «Удалить».

Закройте все окна, затем заново откройте свойства подключения, удалите запись протокола 4 (TCP/IPv4), после чего перезагрузите компьютер.

Теперь ещё раз откройте редактор реестра и разверните ветку KEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Class/ <4D36E972-E325-11CE-BFC1-08002BE10318>. Этот раздел реестра может содержать несколько подразделов. Вам нужен тот, в котором значение параметра DriverDesc будет «Минипорт WAN (IP)». Удалите этот раздел вместе со всем его содержимым, закройте редактор реестра, откройте Диспетчер устройств и, включив в меню вид «Показать скрытые устройства», отыщите в разделе «Сетевые адаптеры» Минипорт WAN (IP) и тоже удалите его. После этого вновь откройте свойства сетевого подключения и вышеописанным способом установите протокол 4 (TCP/IPv4).

Отказ в обслуживании в Microsoft Windows TCP/IP

Из них:
Пользователи: 1120
Проверенные: 8
Друзья: 4
Редакторы:
Журналисты: 8
В вечном бане : 30
Модераторы: 1
Администраторы: 2

Из них:
Парней 976
Девушек 197

Сейчас на сайте:

Кто был?
Фокусник, bai32502522, CD, vovangolovan, ulan_74, День Рождения у: LEOPARD (30) , cheglov2004 (15) , valeryishutin (36)

ПО ЖЕЛАНИЮ, ПОМОЧЬ САЙТУ, ВЫ МОЖЕТЕ ЧЕРЕЗ ПОЖЕРТВОВАНИЕ ЛЮБОЙ СУММЫ.

Статьи: Windows Vista [225] Статьи: Windows 8 [33] Статьи: Медицина и Здоровье [163]
Статьи: Наука и Искусство [35] Статьи: Офис 2010 [125] Статьи: Тестирование железа [4]
Статьи: Photoshop [76] Статьи: История и Политика [5]
О чем вы думаете, когда слышите фразу «устранение неисправностей с TCP/IP»? Люди, которые обладают хорошим воображением могут сразу представить блок-схему. Люди более прямолинейного склада ума могут увидеть последовательность определенных шагов. А все остальные почувствуют себя потерянно и неадекватно.

Устранение неисправностей, связанных с TCP/IP, должно быть просто, верно? Ведь кроме всего, это всего лишь протокол—серия определенных действий по передачи битов по сети. Но что это за протокол – четыре уровня, и несколько протоколов на каждом из уровней.

Традиционный подход

Несколько лет назад, когда я впервые узнал о сетевом протоколе TCP/IP, меня научили следовать следующей последовательности шагов для устранения проблем, связанных с этим протоколом. Метод выглядел как-то вроде этого:

  • Напечатать команду ipconfig для проверки правильности вашего IP адреса, маски подсети (subnet mask) и шлюза по умолчанию (default gateway).
  • Затем запустить команду ping 127.0.0.1. для того, чтобы убедиться, что ваш сетевой адаптер (network adapter) находится в рабочем состоянии.
  • Затем запустить команду ping для IP адреса вашего собственного компьютера.
  • Затем запустить команду ping для IP адреса другого компьютера, находящегося в той же самой подсети (subnet).
  • Затем попытаться запустить команду ping для вашего шлюза по умолчанию (default gateway) (ближний интерфейс маршрутизатора (router), который подключает вашу подсеть (subnet) к остальной сети).
  • Затем попытаться запустить команду ping для IP адреса компьютера в другой подсети.
  • И так далее.

Я называю этот подход безмозглым, или «brain-dead approach», т.к. он настолько методичен, что вы можете просто отключить свои мозги и просто выполнять последовательность шагов. Он также в некотором роде неэффективен, т.к. он автоматически подразумевает, что ваша проблема наиболее вероятно связана с ваши собственным компьютером и тем, что близко к вам расположено (ваше сетевая карта, конфигурация IP адреса вашего компьютера, ваша локальная подсеть), а не с тем, что находится подальше (другие посети). И вероятнее всего, этот метод был разработан до того, как появился интернет, до того, как DNS стал повсеместным для определения имени, и до того, как брандмауэры (firewalls) и VPN стали необходимой частью большинства корпоративных сетей (corporate networks).

За примером далеко ходить не надо – один из ваших пользователей заявляет: «Я сейчас не могу подключиться к серверу». В чем может быть проблема? Достаточно проанализировать это простое предложение, чтобы попробовать понять, в чем может заключаться проблема. Например:

Это единственный пользователь, который сообщил о проблемах в сети? Есть еще пользователи, которые столкнулись с подобными проблемами? Если есть, то вы не должны использовать безмозглый подход (brain-dead approach) и начинать устранение неисправностей с компьютера пользователя. Вместо этого наиболее вероятно, что проблема где-то дальше, например, может быть, выключен ваш сервер DNS server, или же ваш поставщик услуг DNS испытывает временные трудности. Или может быть, маршрутизатор вашей внутренней сети сошел с ума и не пропускает пакеты. Или может быть сервер, к которому пытаются подключиться пользователи, сломался.

Вам стоит также остановиться и подумать о схожести проблем, которые возникли у пользователей. Например, находятся ли их компьютеры в одной подсети? Если да, то, может быть, шлюз по умолчанию для этой подсети неправильно настроен, или сломался маршрутизатор. Или может быть, случайно был поврежден сетевой кабель, который подключает подсеть к основному Ethernet маршрутизатору сети. Или, может быть, некий злоумышленник установил нестандартный DHCP сервер в этой подсети, который переназначил компьютерам новые адреса, для создания атаки типа отказ в обслуживании.

Если это единственные пользователь, у которого возникла такая проблема, то, вероятней всего, пришло время применить безмозглый подход и начать задавать вопросы типа: «Хорошо, а ваш компьютер включен? Сетевой кабель подключен к задней части вашего компьютера?». И все в таком духе.

Неплохо бы задать также пользователю такой вопрос: «А что вы подразумеваете под словом подключиться?» Это необходимо сделать потому, что слово «подключиться» – это техническое слово, которое пользователи часто используют для того, чтобы впечатлить специалиста службы поддержки своими знаниями в этой области. Но, как показывает практика, эти знания обычно отсутствуют. Почему? Потому, что существуют различные типы подключений, включая соединения на уровне MAC, сессии TCP, аутентификация с помощью пароля (password-authentication), права и привилегии на доступ, соединения NAT-traversal, прохождение брандмауэра (firewall pass-through), сессии прикладного уровня (application-level sessions), и так далее. С каким из типов соединения у вас обычно возникают проблемы? Что они обычно пытаются сделать, когда говорят, что хотят подключиться к серверу? Пытаются ли они получить доступ к общей папке на этом сервере? Получают ли они при этом в ответ сообщение «Access denied (доступ запрещен)»? Или же у них появляется окно, требующее ввести имя пользователя и пароль? Или же не подходит их имя пользователя и парольs? Или у них возникли проблемы с поиском общей папки в Active Directory? Может быть у них возникли проблемы с диском (mapped drive)? Может быть у них не получается найти сервер в сетевом окружении (My Network Places)? И так далее.

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

У вас есть пользователь, сервер и сеть между ними. Они не могут подключиться друг к другу. Почему? Хорошо, а где точно находится сервер? Находится ли он в подсети пользователя? В смежной подсети? В другом структурном подразделении? На другом этаже? В другом здании? На другом континенте? Какой тип сети связывает пользователя с соответствующим сервером? Проводная Ethernet LAN? Беспроводная wireless LAN (WLAN)? Обычная линия T1 line? Frame Relay? Туннель VPN tunnel через Интернет (Internet)? Телефонное модемное (dial-up modem) соединение? Кабельный модем или DSL? Сперва определите тип соединения (возможно несколько типов) между пользователем и сервером, а затем уже начинайте думать, что и где могло сломаться. Может быть, сломался CSU/DSU пытаясь соединиться с поставщиком услуг (service provider), который контролирует его. Может быть, уборщица наводила порядок серверной комнате и случайно выключила Ethernet переключатель (switch). Проверьте поступление сообщений тревоги от вашего программного обеспечения по управлению сетью (network management software), в этом случае мы предполагаем, что вы используете управляемые переключатели (managed switches). Может быть, возникли перебои с питанием в удаленном дочернем офисе, в котором располагается сервер. Позвоните им по телефону и спросите, что случилось.

И это сервер или сервера? У пользователя возникли проблемы с подключением к этому серверу или же к другим серверам тоже? У других пользователей возникли подобные проблемы с подключением к другим серверам? Какие есть взаимосвязи (если они есть) между всеми проблемными серверами? (или вероятно проблемными — помните, что проблема может быть с компьютером пользователя или с самой сетью, что более вероятно.)

«…в настоящий момент.»

Элемент времени очень важен для устранения неисправностей. Случилась ли проблема только что? Когда была осуществлена последняя успешная попытка подключения к серверу? Как долго это продолжалось? Это постоянно или временно? Временные сетевые проблемы очень сложно устранить, особенно если они возникают на короткий период времени и возникают случайно.

Время может также помочь вам связать проблему с другими обстоятельствами, касающимися вашей сети. Возникла ли эта проблема сегодня утром в 10 часов? Что еще случилось с вашей сетью network? Устанавливались ли новые обновления на WSUS сервер? Была ли запланирована поддержка контролера домена? Производились ли ремонтные работы в здании в этот момент времени?

Структурный подход

Мой собственный подход в устранении неисправностей TCP/IP (troubleshooting) – это структурный подход, который охватывает три важных области:

  1. Определение проблемных единиц. Это означает:
    • Сторона клиента: клиент или клиенты, у которого возникли трудности или трудность.
    • Сторона сервера: сервер, принтер или другие сетевые ресурсы (например, интернет), с которым возникли трудности у клиента.
    • Сеть между ними (Network): проводная (wires) или беспроводная (wireless), маршрутизаторы (hubs), переключатели (switches), роутеры (routers), брандмауэры (firewalls), прокси сервера (proxy servers) и любая другая инфраструктура (infrastructure) между стороной клиента и стороной сервера.
    • Окружение: внешние обстоятельства, которые могут влиять на вашу сеть, например, перебои с питанием, ремонтные работы по зданию и т.д.
    • Область: может быть вовлечен один или несколько клиентов и серверов.
    • Временной фактор: повторяющиеся, временные, случайные; время начала и т.д.
    • Тип проблемы с соединением: физическая (Physical), сетевая (network), на транспортном или прикладном уровне (transport or application layer), проблема с аутентификацией или контролем доступа и т.д.
    • Признаки: сообщения об ошибках на клиентских компьютерах; меню для входа и т.д.

  1. Определение необходимых этапов отладки, для решения проблем с вышеперечисленными элементами. Это включает в себя:
    • Проверка физического соединения для аппаратного обеспечения клиента, сервера и сетевой инфраструктуры. Это означает проверку кабелей, установки сетевых адаптеров проверка других соединений.
    • Проверка конфигурации TCP/IP аппаратного обеспечения клиента, сервера и сетевой инфраструктуры. Для клиентов и серверов это означает проверку IP адреса, маски подсети, шлюза по умолчанию, параметров DNS и так далее. Для сетевой инфраструктуры это обычно означает проверку таблиц маршрутов на маршрутизаторах и интернет шлюзах .
    • Проверка соединения между клиентом и сервером. Это означает использование инструментов ping, pathping, tracert, и других аналогичных средств для проверки end-to-end TCP/IP соединения на сетевом уровне; сетевой анализ пакетов (packet sniffing) для проверки сессий на транспортном уровне; использование nslookup, telnet и других инструментов для устранения неисправностей на прикладном уровне, устранения проблем, связанных с распознаванием имен и аутентификацией.

  1. Понять, спросить и протестировать.
    • Очень важно понимание принципов работы протокола, как передаются пакеты согласно маршрутным таблицам, как работают инструменты типа Netdiag.exe, и что они могут сообщить. Успешное устранение неисправностей для TCP/IP зависит от понимания принципов работы TCP/IP, и инструментов, которые можно использовать для их проверки. Если вы никогда не пытались понять результаты сетевого мониторинга, то у вас возникнут проблемы определенного типа.
    • Правильные вопросы также существенно помогут в устранении неисправностей. Научитесь быть методичными и тогда вы сможете существенно облегчить себе жизнь и использовать, как логический подход, так и интуитивный.
    • Наконец, очень важно не забывать о тестировании, и попытаться изолировать проблему, а для этого необходимо уметь работать с инструментами для устранения неисправностей. При решении сложных проблем вам сможет помочь ваш личный опыт.

Заключение

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

Автор: Митч Туллоч (Mitch Tulloch)

Если на странице вы заметили в посте отсутствие изображений, просьба сообщить , нажав на кнопку.

После прочтения материала » Проблемы и решения: Устранение неисправностей TCP/IP: Структурный подход (Часть 1) «, можно просмотреть форум и поискать темы по данной игре.

ДРУГИЕ МАТЕРИАЛЫ
Первые оценки Mercenaries 2
StarCraft 2 выйдет в 2009 году
Платформа AMD Tigris будет анонсирована в сентябре
Warhammer Online: скрины и интервью
Сколько Blizzard потратила на WoW
Computex 2009: Intel делает ставку на CULV-ноутбуки
WEB Почта — достоинства и недостатки
Новый формат «ударит» по Blu-ray и HD DVD в октябре
Совет недели по групповым политикам 8 – Управление электропитанием
Яндекс улучшил фильтрацию контента для взрослых
HX850W и HX750W: экономичные и бесшумные БП от Corsair
IDF SF 2008: революция в мире систем охлаждения от Intel?
Официальный анонс Palit Radeon HD 4870 Sonic Dual Edition
Мила Йовович говорит о следующей части Resident Evil
Беспроводный комплект Cordless Desktop Wave Pro от Logitech
Radeon HD 4860 — прямая угроза GeForce GTS 250?
Официальный трейлер аддона Fallout 3: Mothership Zeta
Реорганизация AMD приведет к отказу от бренда ATI
Duke Begins была приостановлена
Дмитрий Медведев побывал в «Лаборатории Касперского»

Если вам понравился материал «Проблемы и решения: Устранение неисправностей TCP/IP: Структурный подход (Часть 1)», — поделитесь ним с другими.

html-cсылка на публикацию
BB-cсылка на публикацию
Прямая ссылка на публикацию
Категория : Статьи: Windows Vista | Добавил : Фокусник (04.10.2009)
Просмотров : 1939
Ниже вы можете добавить комментарии к материалу » Проблемы и решения: Устранение неисправностей TCP/IP: Структурный подход (Часть 1) «

Внимание: Все ссылки и не относящиеся к теме комментарии будут удаляться. Для ссылок есть форум.

Отказ в обслуживании в Microsoft Windows TCP/IP

Чтобы определить причину проблем, возникающих при подключении по протоколу TCP/IP в Windows XP, можно воспользоваться рядом служебных программ. В этой статье приводятся рекомендации по использованию этих средств для диагностики сетевых проблем. Хотя данный список рекомендаций нельзя считать исчерпывающим, в нем содержатся примеры, иллюстрирующие использование средств для определения причин сетевых проблем.

Дополнительная информация

Диагностические средства TCP/IP

Ниже приведены некоторые диагностические средства TCP/IP, входящие в Windows XP.

Основные средства

Диагностика сети в справке и поддержке
Подробные сведения о конфигурации сети и результатах автоматически выполняемых тестов.
Папка «Сетевые подключения»
Она содержит сведения о всех сетевых подключениях на компьютере и их настройках. Чтобы открыть папку «Сетевые подключения», нажмите кнопку Пуск, выберите команду Панель управления, затем щелкните значок Сетевые подключения.
Команда IPConfig
Отображает текущие значения конфигурации сети TCP/IP, обновляет или освобождает адреса, назначенные сервером DHCP, а также отображает, регистрирует или освобождает имена DNS.
Команда Ping
Отправляет сообщения с эхо-запросами по протоколу ICMP, чтобы проверить правильность настройки TCP/IP и доступность узла TCP/IP.

Дополнительные средства

Команда Hostname
Отображает имя узла.
Команда Nbtstat
Отображает сведения о текущих соединениях NetBIOS поверх TCP/IP, обновляет кэш имен NetBIOS и отображает зарегистрированные имена и код области.
Команда PathPing
Отображает путь к узлу TCP/IP и сообщает о потерях данных на каждом маршрутизаторе по пути следования пакета.
Команда Route
Отображает таблицу IP-маршрутизации и добавляет или удаляет маршруты IP.
Команда Tracert
Отображает путь узла TCP/IP.

Чтобы узнать синтаксис вызова любого из перечисленных средств, наберите в командной строке после его имени -? .

Средства Windows XP Professional

Windows XP Professional включает следующие дополнительные средства:

Просмотр событий
Записывает системные ошибки и события.
Управление компьютером
Вносит изменения в драйверы сетевых интерфейсов и другие системные компоненты.

Устранение неполадок

Процедура устранения неполадок TCP/IP зависит от используемого типа подключения и проблемы.

Автоматическое устранение неполадок

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

1. Нажмите кнопку Пуск и выберите команду Справка и поддержка.
2. Щелкните ссылку Использование служебных программ для просмотра информации о компьютере и диагностики неполадок, а затем в списке слева выберите пункт Диагностика сети.
3. Если выбрать пункт Собрать информацию, средство сетевой диагностики соберет сведения о настройке и выполнит автоматический поиск неисправностей, связанных с сетевым подключением.
4. Когда процесс завершится, отметьте любой элемент, помеченный красным шрифтом как FAILED, чтобы раскрыть его и просмотреть дополнительные сведения о результатах проверки.

Затем можно использовать полученные сведения для самостоятельного решения проблемы или обратиться за помощью к специалисту службы технической поддержки, предоставив ему эти сведения. Сравнив результаты тестов, выявивших проблемы, с документацией в разделе «Разрешение проблем вручную» (см. далее в этой статье), можно определить источник неполадки. Для интерпретации результатов по подключению TCP/IP разверните раздел «Сетевые адаптеры», а затем — сетевой адаптер, при проверке которого были выявлены ошибки.

Интерфейс диагностики сети может быть также запущен напрямую с помощью следующей команды:


Устранение неполадок вручную

Для устранения неполадок подключений TCP/IP вручную следует использовать указанные способы в следующем порядке:

Способ 1. Проверка конфигурации с помощью средства IPConfig

Чтобы проверить конфигурацию TCP/IP на компьютере, где обнаружена проблема, с помощью средства IPConfig, нажмите кнопку Пуск, выберите пункт Выполнить и введите команду cmd . Для получения сведений о конфигурации компьютера, включая его IP-адрес, маску подсети и шлюз по умолчанию, можно использовать программу ipconfig.

Если указать для IPConfig параметр /all, будет создан подробный отчет о конфигурации всех интерфейсов, включая адаптеры удаленного доступа. Отчет IPConfig можно записать в файл, что позволит вставлять его в другие документы. Для этого введите команду

В результате отчет будет сохранен в файле с указанным именем и помещен в указанную папку.

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

Если компьютер имеет IP-адрес 169.254. y . z и маску подсети 255.255.0.0, то IP-адрес был назначен средством автоматического назначения IP-адресов APIPA операционной системы Windows XP Professional. Это означает, что TCP/IP настроен для автоматической конфигурации, сервер DHCP не был найден и не была указана альтернативная конфигурация. В этой конфигурации для интерфейса не задан шлюз по умолчанию.

Если компьютер имеет IP-адрес 0.0.0.0, значит, он был переопределен средством опроса носителя DHCP. Это может быть вызвано тем, что сетевой адаптер не обнаружил подключения к сети, или тем, что протокол TCP/IP обнаружил IP-адрес, который дублирует присвоенный вручную адрес компьютера.

Если не удалось определить проблемы в конфигурации TCP/IP, перейдите к способу 2.

Способ 2. Проверка подключения с помощью средства Ping

Если в конфигурации TCP/IP не было обнаружено ошибок, проверьте возможность подключения компьютера к другим компьютерам в сети TCP/IP. Для этого используется средство Ping.

С помощью средства Ping можно проверить подключение на уровне IP. Команда ping отправляет на другой компьютер сообщение с эхо-запросом по протоколу ICMP. С помощью средства Ping можно узнать, может ли главный компьютер отправлять IP-пакеты на компьютер-получатель. Команду Ping можно также использовать для выявления того, чем вызвана проблема – неполадкой сетевых устройств или несовместимостью конфигураций.

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

Примечание IP-адрес является IP-адресом узла сети, к которому требуется подключиться.

Чтобы использовать команду ping, выполните следующие действия:

1. Задайте адрес замыкания на себя, чтобы проверить правильность настройки и установки TCP/IP на локальном компьютере. Для этого служит следующая команда:

Если контроль по обратной связи завершится ошибкой, это означает, что стек IP не отвечает. Подобное поведение наблюдается в следующих случаях:

Повреждены драйвера TCP.
Не работает сетевой адаптер.
Другая служба мешает работе протокола IP.
2. Обратитесь по IP-адресу локального компьютера, чтобы убедиться в том, что он был правильно добавлен в сеть. Если таблица маршрутизации не содержит ошибок, эта процедура просто приведет к направлению пакета по адресу замыкания на себя 127.0.0.1. Для этого служит следующая команда:
Если контроль по обратной связи выполнен успешно, но локальный IP-адрес не отвечает, возможно, проблема заключается в таблице маршрутизации драйвера сетевого адаптера.
3. Обратитесь по IP-адресу шлюза по умолчанию, чтобы проверить его работоспособность и возможность связи с локальным узлом локальной сети. Для этого служит следующая команда:
Если обращение завершилось неудачно, это может означать, что проблема заключается в сетевом адаптере, маршрутизаторе/шлюзе, кабеле или другом сетевом устройстве.
4. Обратитесь по IP-адресу удаленного узла, чтобы проверить возможность связи через маршрутизатор. Для этого служит следующая команда:
Если обращение завершилось неудачно, это может означать, что удаленный узел не отвечает или проблема заключается в сетевых устройствах между компьютерами. Чтобы исключить возможность отсутствия ответа удаленного узла, проверьте связь с другим удаленным узлом с помощью команды Ping.
5. Обратитесь по IP-адресу удаленного узла, чтобы проверить, может ли быть разрешено имя удаленного узла. Для этого служит следующая команда:

Команда Ping использует разрешение имен для разрешения имени компьютера в IP-адрес. Поэтому, если обращение по IP-адресу производится успешно, а обращение по имени – неудачно, проблема заключается в разрешении имени узла, а не в сетевом подключении. Проверьте, настроены ли для компьютера адреса сервера DNS (вручную в свойствах TCP/IP или автоматически). Если адреса сервера DNS выводятся командой ipconfig /all, обратитесь по адресам сервера, чтобы проверить, доступны ли они.

Если на одном из этапов использования средства Ping возникают ошибки, выполните следующие действия:

Убедитесь, что IP-адрес локального компьютера действителен и правильно задан на вкладке Общие диалогового окна Свойства протокола Интернета (TCP/IP) или с помощью средства Ipconfig.
Убедитесь, что настроен шлюз по умолчанию и имеется связь между узлом и шлюзом по умолчанию. Для разрешения проблем должен быть настроен только один шлюз по умолчанию. Хотя шлюзов по умолчанию может быть несколько, все шлюзы кроме первого используются только тогда, когда стек IP определяет, что первый шлюз не работает. При устранении неполадок определяется состояние первого из настроенных шлюзов. Для облегчения задачи все остальные шлюзы можно удалить.
Убедитесь, что отключен протокол безопасности IPSec. При некоторых политиках IPSec пакеты Ping могут блокироваться или требовать защищенного подключения. Дополнительные сведения о протоколе IPSec см. в способе 7. Проверка протокола IPSec

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

Способ 3. Проверка маршрутизации с помощью средства PathPing

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

Способ 4. Очистка кэша ARP с помощью средства Arp

Если обращение по адресу замыкания на себя (127.0.0.1) и собственному IP-адресу выполняется успешно, но ко всем остальным IP-адресам обратиться не удается, попытайтесь очистить кэш протокола ARP (Address Resolution Protocol, протокол разрешения адресов). С помощью командной строки выполните одну из следующих команд.

Способ 5: Проверка шлюза по умолчанию

Адрес шлюза должен находится в той же сети, что и локальный узел. Иначе сообщения компьютера не будут передаваться вне локальной сети. Если адрес шлюза принадлежит той же сети, что и узел, убедитесь, что адрес шлюза по умолчанию корректен. Шлюз по умолчанию должен являться маршрутизатором, а не только узлом. Маршрутизатор должен иметь возможность передавать IP-датаграммы.

Способ 6. Проверка связи с помощью средств Tracert или Route

Если шлюз по умолчанию отвечает правильно, обратитесь к удаленному узлу, чтобы убедится в правильной работе межсетевых соединений. Если эти соединения работают некорректно, проследите путь сообщения к получателю с помощью служебной программы Tracert. Для IP-маршрутизаторов, которые являются компьютерами с операционной системой Microsoft Windows 2000 или Microsoft Windows NT 4.0, просмотрите таблицу IP-маршрутизации с помощью средства маршрутизации или оснастки «Маршрутизация и удаленный доступ» этих компьютеров. На других IP-маршрутизаторах для просмотра таблицы IP-маршрутизации используйте средство, указанное поставщиком используемой операционной системы.

В большинстве случаев при использовании команды Ping отображаются четыре следующих сообщения об ошибках:

Это сообщение об ошибке означает, что не удается разрешить имя узла-получателя. Проверьте имя и доступность серверов DNS или WINS.

Способ 7. Проверка протокола IPSec

IPSec может усилить безопасность в сети, но усложнить изменение конфигурации сети и устранение неполадок. В некоторых случаях политика IPSec требует защищенного подключения для компьютера под управлением Windows XP Professional. Это требование затрудняет установку подключения к удаленному узлу. Если службы IPSec развернуты на локальном узле, можно отключить их в оснастке «Службы».

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

Способ 8. Проверка фильтрации пакетов

Ошибки при фильтрации пакетов могут нарушить работу системы разрешения адресов или подключения. Чтобы узнать, является ли фильтрация пакетов источником проблемы, отключите фильтрацию пакетов TCP/IP. Для этого выполните следующие действия.

1. Нажмите кнопку Пуск и последовательно выберите пункты Панель управления, Сеть и подключения к Интернету и Сетевые подключения.
2. Щелкните правой кнопкой мыши значок подключения по локальной сети, которое требуется изменить, и выберите пункт Свойства.
3. На вкладке Общие в списке Отмеченные компоненты используются этим подключением выберите вариант Протокол Интернета (TCP/IP) и нажмите кнопку Свойства.
4. Нажмите кнопку Дополнительно и перейдите на вкладку Параметры.
5. В диалоговом окне Необязательные параметры выберите элемент Фильтрация TCP/IP и нажмите кнопку Свойства.
6. Снимите флажок Задействовать фильтрацию TCP/IP (все адаптеры) и нажмите кнопку OK.

Попробуйте обратиться к адресу по его имени DNS, имени NetBIOS компьютера или IP-адресу. Если обращение выполнено успешно, возможно, параметры фильтрации были неправильно установлены или накладывают слишком жесткие ограничения. Например, фильтрация может разрешить компьютеру выступать в роли веб-сервера, но отключить ряд средств, таких как удаленное администрирование. Чтобы расширить диапазон допустимых параметров фильтрации, измените допустимые значения для порта TCP, порта UDP и протокола IP.

Способ 9. Проверка подключения к определенному серверу

Чтобы определить причину проблемы при подключении к серверу через NetBIOS, выполните команду nbtstat -n на этом сервере. Это позволит узнать, под каким именем сервер зарегистрирован в сети.

Команда nbtstat -n выводит несколько имен, под которыми зарегистрирован компьютер. Среди этих имен должно быть имя, похожее на то, которое указано на вкладке Имя компьютера окна Система, доступного с панели управления. Если такого имени нет, попытайтесь использовать любое другое уникальное имя, выведенное командой nbtstat.

Средство Nbtstat также может отображать кэшированные записи удаленных компьютеров, которые отмечены #PRE в файле Lmhosts или относятся к недавно разрешенным именам. Если удаленные компьютеры используют для сервера одно и то же имя, а другие компьютеры находятся в удаленной подсети, убедитесь, что для них задано соответствие «имя-адрес» в файлах Lmhosts или в серверах WINS.

Способ 10. Проверка удаленных подключений

Чтобы определить, почему не устанавливается подключение по протоколу TCP/IP с удаленным компьютером, выполните команду netstat -a, показывающую состояние всех портов TCP и UDP локального компьютера.

Если подключение TCP работает нормально, в очередях Sent (Отправлено) и Received (Получено) отображается 0 байт. Если в одной из этих очередей данные блокируются или они имеют состояние «irregular», подключение может быть неисправно. Если данные не блокируются, а очереди находятся в состоянии «typical», то проблема, вероятно, вызвана задержкой в работе сети или программе.

Способ 11. Проверка таблицы маршрутизации с помощью средства Route

Для того чтобы два узла могли обмениваться IP-датаграммами, они должны иметь маршруты друг к другу или использовать шлюзы по умолчанию, где имеются эти маршруты. Чтобы просмотреть таблицу маршрутизации на компьютере под управлением Windows XP, введите команду

Способ 12: Проверка путей с помощью средства Tracert

Средство Tracert отправляет сообщения с эхо-запросами, увеличивая на каждом шаге значения в IP-заголовке поля TTL, чтобы определить сетевой путь между двумя узлами. Затем средство Tracert анализирует возвращенные сообщения ICMP. Tracert позволяет прослеживать путь, не превышающий 30 прыжков. Tracert определяет причину проблемы, когда при проходе через какой-либо маршрутизатор происходит ошибка или маршрут образует замкнутый цикл. После того, как маршрутизатор, являющийся причиной проблемы, обнаружен, обратитесь к администратору маршрутизатора, если маршрутизатор находится в другой сети, или сами восстановите работоспособность маршрутизатора, если он находится под вашим управлением.

Способ 13. Устранение неполадок в шлюзах

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

Сравните часть IP-адреса шлюза по умолчанию, соответствующую идентификатору сети, с идентификаторами сети сетевых адаптеров компьютера. В частности, проверьте, равен ли результат логического поразрядного И IP-адреса и маски подсети результату логического поразрядного И основного шлюза и маски подсети.

Например, если компьютер имеет один сетевой адаптер с IP-адресом 172.16.27.139 и маской подсети 255.255.0.0, шлюз по умолчанию должен иметь адрес 172.16.y.z. y . z . Идентификатор сети для этого интерфейса IP — 172.16.0.0.

Дополнительные ресурсы

Перечисленные ниже ресурсы содержат дополнительные сведения по разрешению проблем TCP/IP:

Раздел Configuring TCP/IP (Настройка TCP/IP) документации к пакету ресурсов Microsoft Windows XP Professional Resource Kit.

Раздел Introduction to TCP/IP (Общие сведения о TCP/IP) руководства TCP/IP Core Networking Guide, входящего в пакет ресурсов Microsoft Windows 2000 Server Resource Kit, содержит общие сведения о наборе протоколов TCP/IP.

Раздел Unicast Routing Overview (Общие сведения об одноадресной маршрутизации) руководства Internetworking Guide, входящего в пакет ресурсов Microsoft Windows 2000 Server Resource Kit, содержит дополнительные сведения о принципах маршрутизации.

Раздел TCP/IP Troubleshooting (Устранение неполадок TCP/IP) руководства TCP/IP Core Networking Guide, входящего в пакет ресурсов Microsoft Windows 2000 Server Resource Kit, содержит дополнительные сведения о фильтрации пакетов IP.

способы устранения неполадок TCP/IP

#1 Гость

на днях тут в очередной раз упала сеть,а я по своей глупости р*цензура*нул комп. после чего подключение есть- сети нет. нарыл тут одну полезную статейку — может кому пригодиться.
(мне помогли пункты 5 и 7 )
а вот в техподдержке этого не знали.

13 способов, как устранить руками неполадки подключений по протоколу TCP/IP в Windows XP.

Способ 1. Проверка конфигурации с помощью средства IPConfig

Чтобы проверить конфигурацию TCP/IP на компьютере, где обнаружена проблема, с помощью средства IPConfig, нажмите кнопку Пуск, выберите пункт Выполнить и введите команду cmd. Для получения сведений о конфигурации компьютера, включая его IP-адрес, маску подсети и шлюз по умолчанию, можно использовать программу ipconfig.

Если указать для IPConfig параметр /all, будет создан подробный отчет о конфигурации всех интерфейсов, включая адаптеры удаленного доступа. Отчет IPConfig можно записать в файл, что позволит вставлять его в другие документы. Для этого введите команду ipconfig > имя_папкиимя_файла В результате отчет будет сохранен в файле с указанным именем и помещен в указанную папку.

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

Если компьютер имеет IP-адрес 169.254.y.z и маску подсети 255.255.0.0, то IP-адрес был назначен средством автоматического назначения IP-адресов APIPA операционной системы Windows XP Professional. Это означает, что TCP/IP настроен для автоматической конфигурации, сервер DHCP не был найден и не была указана альтернативная конфигурация. В этой конфигурации для интерфейса не задан шлюз по умолчанию.

Если компьютер имеет IP-адрес 0.0.0.0, значит, он был переопределен средством опроса носителя DHCP. Это может быть вызвано тем, что сетевой адаптер не обнаружил подключения к сети, или тем, что протокол TCP/IP обнаружил IP-адрес, который дублирует присвоенный вручную адрес компьютера.

Если не удалось определить проблемы в конфигурации TCP/IP, перейдите к способу 2

Способ 2. Проверка подключения с помощью средства Ping

Если в конфигурации TCP/IP не было обнаружено ошибок, проверьте возможность подключения компьютера к другим компьютерам в сети TCP/IP. Для этого используется средство Ping.

С помощью средства Ping можно проверить подключение на уровне IP. Ко*цензура* ping отправляет на другой компьютер сообщение с эхо-запросом по протоколу ICMP. С помощью средства Ping можно узнать, может ли главный компьютер отправлять IP-пакеты на компьютер-получатель. Команду Ping можно также использовать для выявления того, чем вызвана проблема – неполадкой сетевых устройств или несовместимостью конфигураций.

Примечание Если была выполнена ко*цензура* ipconfig /all и отобразилась конфигурация IP, то адрес замыкания на себя и IP-адрес компьютера не нужно проверять с помощью команды Ping. Эти задачи уже были выполнены командой IPConfig при выводе конфигурации. При устранении неполадок следует убедиться, что существует маршрутизация между локальным компьютером и узлом сети. Для этого используется ко*цензура* ping IP-адрес

Примечание IP-адрес является IP-адресом узла сети, к которому требуется подключиться.

Чтобы использовать команду ping, выполните следующие действия:

1. Задайте адрес замыкания на себя, чтобы проверить правильность настройки и установки TCP/IP на локальном компьютере. Для этого служит следующая ко*цензура*: ping 127.0.0.1 Если контроль по обратной связи завершится ошибкой, это означает, что стек IP не отвечает.

Подобное поведение наблюдается в следующих случаях:

• Повреждены драйвера TCP.

• Не работает сетевой адаптер.

• Другая служба мешает работе протокола IP.

2. Обратитесь по IP-адресу локального компьютера, чтобы убедиться в том, что он был правильно добавлен в сеть. Если таблица маршрутизации не содержит ошибок, эта процедура просто приведет к направлению пакета по адресу замыкания на себя 127.0.0.1.

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

3. Обратитесь по IP-адресу шлюза по умолчанию, чтобы проверить его работоспособность и возможность связи с локальным узлом локальной сети. Для этого служит следующая ко*цензура*: ping IP-адрес шлюза по умолчанию Если обращение завершилось неудачно, это может означать, что проблема заключается в сетевом адаптере, маршрутизаторе/шлюзе, кабеле или другом сетевом устройстве.

4. Обратитесь по IP-адресу удаленного узла, чтобы проверить возможность связи через маршрутизатор. Для этого служит следующая ко*цензура*: ping IP-адрес удаленного узла. Если обращение завершилось неудачно, это может означать, что удаленный узел не отвечает или проблема заключается в сетевых устройствах между компьютерами. Чтобы исключить возможность отсутствия ответа удаленного узла, проверьте связь с другим удаленным узлом с помощью команды Ping.

5. Обратитесь по IP-адресу удаленного узла, чтобы проверить, может ли быть разрешено имя удаленного узла. Для этого служит следующая ко*цензура*: ping имя удаленного узла Ко*цензура* Ping использует разрешение имен для разрешения имени компьютера в IP-адрес. Поэтому, если обращение по IP-адресу производится успешно, а обращение по имени – неудачно, проблема заключается в разрешении имени узла, а не в сетевом подключении. Проверьте, настроены ли для компьютера адреса сервера DNS (вручную в свойствах TCP/IP или автоматически). Если адреса сервера DNS выводятся командой ipconfig /all, обратитесь по адресам сервера, чтобы проверить, доступны ли они.

Если на одном из этапов использования средства Ping возникают ошибки, выполните следующие действия:

• Убедитесь, что IP-адрес локального компьютера действителен и правильно задан на вкладке Общие диалогового окна Свойства протокола Интернета (TCP/IP) или с помощью средства Ipconfig.

• Убедитесь, что настроен шлюз по умолчанию и имеется связь между узлом и шлюзом по умолчанию. Для разрешения проблем должен быть настроен только один шлюз по умолчанию. Хотя шлюзов по умолчанию может быть несколько, все шлюзы кроме первого используются только тогда, когда стек IP определяет, что первый шлюз не работает. При устранении неполадок определяется состояние первого из настроенных шлюзов. Для облегчения задачи все остальные шлюзы можно удалить.

• Убедитесь, что отключен протокол безопасности IPSec. При некоторых политиках IPSec пакеты Ping могут блокироваться или требовать защищенного подключения. Дополнительные сведения о протоколе IPSec см. в способе

7. Проверка протокола IPSec Внимание! Если соединение с удаленной системой, к которой происходит обращение, имеет большое время задержки (это относится, например, к спутниковой линии связи), возможно, ответа придется ждать дольше. С помощью параметра -w можно задать более продолжительный период ожидания, чем период по умолчанию, равный 4 секундам.

Способ 3. Проверка маршрутизации с помощью средства PathPing

PathPing – это средство, выявляющее потери пакета на маршрутах, включающих несколько прыжков. Обратившись с помощью PathPing к удаленному узлу, можно убедиться, что маршрутизаторы, через которые проходит пакет, работают нормально. Для этого служит следующая ко*цензура*: pathping IP-адрес удаленного узла

Способ 4. Очистка кэша ARP с помощью средства Arp

Если обращение по адресу замыкания на себя (127.0.0.1) и собственному IP-адресу выполняется успешно, но ко всем остальным IP-адресам обратиться не удается, попытайтесь очистить кэш протокола ARP (Address Resolution Protocol, протокол разрешения адресов).

С помощью командной строки выполните одну из следующих команд.

arp -a (тоже самое arp -g )

Чтобы удалить записи, введите команду

Для очистки кэша ARP используется следующая ко*цензура*:

netsh interface ip delete arpcache

Способ 5. Проверка шлюза по умолчанию

Адрес шлюза должен находится в той же сети, что и локальный узел. Иначе сообщения компьютера не будут передаваться вне локальной сети. Если адрес шлюза принадлежит той же сети, что и узел, убедитесь, что адрес шлюза по умолчанию корректен. Шлюз по умолчанию должен являться маршрутизатором, а не только узлом. Маршрутизатор должен иметь возможность передавать IP-датаграммы.

Способ 6. Проверка связи с помощью средств Tracert или Route

Если шлюз по умолчанию отвечает правильно, обратитесь к удаленному узлу, чтобы убедится в правильной работе межсетевых соединений. Если эти соединения работают некорректно, проследите путь сообщения к получателю с помощью служебной программы Tracert. Для IP-маршрутизаторов, которые являются компьютерами с операционной системой Microsoft Windows 2000 или Microsoft Windows NT 4.0, просмотрите таблицу IP-маршрутизации с помощью средства маршрутизации или оснастки «Маршрутизация и удаленный доступ» этих компьютеров. На других IP-маршрутизаторах для просмотра таблицы IP-маршрутизации используйте средство, указанное поставщиком используемой операционной системы.

В большинстве случаев при использовании команды Ping отображаются четыре следующих сообщения об ошибках: TTL


Expired in Transit Это сообщение об ошибке означает, что количество требуемых проходов через маршрутизатор превышает время жизни (TTL). Время жизни можно увеличить с помощью команды ping-i. Возможно, причина этой ошибки в том, что в маршрут является циклическим.

Чтобы узнать, действительно ли возник циклический маршрут (из-за неправильной конфигурации маршрутизаторов), используйте команду Tracert

Destination Host Unreachable Это сообщение об ошибке означает, что к узлу-получателю нет локального или удаленного маршрута (на узле-отправителе или маршрутизаторе). Проверьте таблицу маршрутизации на локальном узле или маршрутизаторе.

Request Timed Out Это сообщение об ошибке означает, что сообщения с эхо-запросами не были получены в течение заданного периода ожидания. По умолчанию он равен 4 секундам. Период ожидания можно увеличить с помощью команды ping -w.

Ping request could not find host Это сообщение об ошибке означает, что не удается разрешить имя узла-получателя. Проверьте имя и доступность серверов DNS или WINS.

Способ 7. Проверка протокола IPSec

IPSec может усилить безопасность в сети, но усложнить изменение конфигурации сети и устранение неполадок. В некоторых случаях политика IPSec требует защищенного подключения для компьютера под управлением Windows XP Professional. Это требование затрудняет установку подключения к удаленному узлу. Если службы IPSec развернуты на локальном узле, можно отключить их в оснастке «Службы».

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

Способ 8. Проверка фильтрации пакетов

Ошибки при фильтрации пакетов могут нарушить работу системы разрешения адресов или подключения. Чтобы узнать, является ли фильтрация пакетов источником проблемы, отключите фильтрацию пакетов TCP/IP.

Для этого выполните следующие действия.

1. Нажмите кнопку Пуск и последовательно выберите пункты Панель управления, Сеть и подключения к Интернету и Сетевые подключения.

2. Щелкните правой кнопкой мыши значок подключения по локальной сети, которое требуется изменить, и выберите пункт Свойства.

3. На вкладке Общие в списке Отмеченные компоненты используются этим подключением выберите вариант Протокол Интернета (TCP/IP) и нажмите кнопку Свойства.

4. Нажмите кнопку Дополнительно и перейдите на вкладку Параметры.

5. В диалоговом окне Необязательные параметры выберите элемент Фильтрация TCP/IP и нажмите кнопку Свойства.

6. Снимите флажок Задействовать фильтрацию TCP/IP (все адаптеры) и нажмите кнопку OK. Попробуйте обратиться к адресу по его имени DNS, имени NetBIOS компьютера или IP-адресу. Если обращение выполнено успешно, возможно, параметры фильтрации были неправильно установлены или накладывают слишком жесткие ограничения. Например, фильтрация может разрешить компьютеру выступать в роли веб-сервера, но отключить ряд средств, таких как удаленное администрирование. Чтобы расширить диапазон допустимых параметров фильтрации, измените допустимые значения для порта TCP, порта UDP и протокола IP.

Способ 9. Проверка подключения к определенному серверу

Чтобы определить причину проблемы при подключении к серверу через NetBIOS, выполните команду nbtstat -n на этом сервере. Это позволит узнать, под каким именем сервер зарегистрирован в сети.

Ко*цензура* nbtstat -n выводит несколько имен, под которыми зарегистрирован компьютер. Среди этих имен должно быть имя, похожее на то, которое указано на вкладке Имя компьютера окна Система, доступного с панели управления. Если такого имени нет, попытайтесь использовать любое другое уникальное имя, выведенное командой nbtstat.

Средство Nbtstat также может отображать кэшированные записи удаленных компьютеров, которые отмечены #PRE в файле Lmhosts или относятся к недавно разрешенным именам.

Если удаленные компьютеры используют для сервера одно и то же имя, а другие компьютеры находятся в удаленной подсети, убедитесь, что для них задано соответствие «имя-адрес» в файлах Lmhosts или в серверах WINS.

Способ 10. Проверка удаленных подключений

Чтобы определить, почему не устанавливается подключение по протоколу TCP/IP с удаленным компьютером, выполните команду netstat -a, показывающую состояние всех портов TCP и UDP локального компьютера.

Если подключение TCP работает нормально, в очередях Sent (Отправлено) и Received (Получено) отображается 0 байт.

Если в одной из этих очередей данные блокируются или они имеют состояние «irregular», подключение может быть неисправно.

Если данные не блокируются, а очереди находятся в состоянии «typical», то проблема, вероятно, вызвана задержкой в работе сети или программе.

Способ 11. Проверка таблицы маршрутизации с помощью средства Route

Для того чтобы два узла могли обмениваться IP-датаграммами, они должны иметь маршруты друг к другу или использовать шлюзы по умолчанию, где имеются эти маршруты. Чтобы просмотреть таблицу маршрутизации на компьютере под управлением Windows XP, введите команду route print

Способ 12. Проверка путей с помощью средства Tracert

Средство Tracert отправляет сообщения с эхо-запросами, увеличивая на каждом шаге значения в IP-заголовке поля TTL, чтобы определить сетевой путь между двумя узлами. Затем средство Tracert анализирует возвращенные сообщения ICMP.

Tracert позволяет прослеживать путь, не превышающий 30 прыжков.

Tracert определяет причину проблемы, когда при проходе через какой-либо маршрутизатор происходит ошибка или маршрут образует замкнутый цикл.

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

Способ 13. Устранение неполадок в шлюзах

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

Your default gateway does not belong to one of the configured interfaces

Сравните часть IP-адреса шлюза по умолчанию, соответствующую идентификатору сети, с идентификаторами сети сетевых адаптеров компьютера. В частности, проверьте, равен ли результат логического поразрядного И IP-адреса и маски подсети результату логического поразрядного И основного шлюза и маски подсети.

Например, если компьютер имеет один сетевой адаптер с IP-адресом 172.16.27.139 и маской подсети 255.255.0.0, шлюз по умолчанию должен иметь адрес 172.16.y.z.y.z. Идентификатор сети для этого интерфейса IP — 172.16.0.0.

———————————————————————————
от себя добавлю 14-й — если не помогает, зайдите в DOS, format c: и ставте заново — у вас наверное вирус

Атаки на отказ в обслуживании: практика тестирования

Пост — резюме

Думаю, начать стоит с того, что в последнее время все больше заказчиков обращаются не только за тестированием на проникновение, но и за проверкой устойчивости их сервисов к атакам на отказ в обслуживании, чаще всего — веб-сайтов. И на нашей практике пока не было ни одного случая, чтобы реальный работающий сайт (не заранее подготовленная площадка) не вышел из строя, в т.ч. находящийся под разными защитными системами. И этот пост — резюмирование текущего опыта (D)DoS тестирования разными методами совершенно разных инфраструктур (от банков до типичных корпоративных сайтов).

Итак, давайте еще раз. Задача — вывести ресурс из строя любыми доступными методами, будь мы злоумышленниками. В 99% в качестве исходных данных дается домен/IP.

Как проходит работа?

Для начала выбирается методика тестирования и согласовывается с заказчиком. Выбор состоит из:

  • Атаки на канал (достигнуть максимальной пропускной способности);
  • Атаки на сетевые сервисы (slow http, использование эксплойтов для ддоса определенных веб-серверов, атаки на SSL, другие техники);
  • И самое крутое и интересное — атака на application уровень (использование особенностей работы данного приложения).

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

Восстановление стека TCP/IP

Что делать если не работают сетевые протоколы? При попытки пропинговать сервер / ip-адресс вы получаете ошибку «Не удается обратиться к драйверу IP. Код ошибки 2»? Тогда у вас что-то со стеком TCP/IP, разберём подробнее.

Начну с лёгкого и простого, заканчивая более сложными решениями проблемы.

Возможно у вас на компьютере стоит Аваст и проблемы начались после обновления антивирусных баз, 6 декабря 2012 года аваст добавил в свои базы файл C:\Windows\system32\drivers\TCPIP.sys , вскоре после обновления баз аваст нашёл этот файл в системных файлах и удалил (возможно поместил в карантин).

Не беда, ниже я напишу как восстановить работоспособность стека TCP/IP, после чего сеть должна заработать (если она конечно раньше работала):

1. Самый простой способ — воспользоваться avastfix.zip зеркало :

  • для начала нужно скачать avastfix (ссылки строчкой выше)
  • распаковать, допустим на диск C:\ (в архиве есть папка, так что после извлечения будет путь такой C:\avastfix\ )
  • если у вас стоит аваст, то отключите его: в правом нижнем углу найдите значок аваста (возле часов), нажмите на него правой кнопкой мышки и выберите управление экранами avast , далее нужно указать отключение навсегда
  • запустите fixtcpip.bat , после чего компьютер перезагрузится
  • после перезагрузки проверяем работу сети например пингом на сервер гугла: на клавиатуре нажмите одновременно на флажок (логотип windows), между Ctrl и Alt , и букву R , то есть Win + R . В появившемся окне напишите cmd , у вас открылась командная строка, в ней напишите ping 8.8.8.8 , должно появиться

Обмен пакетами с 8.8.8.8 по 32 байт:

Ответ от 8.8.8.8: число байт=32 время=55мс TTL=48

или что-то похожее, но не ошибка драйвера сети

  • надеюсь сеть/интернет у вас заработал, теперь нужно обновить базы аваста, если нет возможности обновить, то можно в настройках аваста исключить из проверки этот файл:
    C:\Windows\system32\drivers\TCPIP.sys (у вас может быть установлен windows на другой раздел, например D: )
  • теперь можно включить антивирус, там же где вы его отключали, только теперь включить все экраны
  • Давайте теперь рассмотрим что в этом «чудо» архиве:
    fixtcpip.bat — некий скрипт, который импортирует в реестр стандартные настройки стека, распаковывает архив tcpip.rar при помощи UnRAR.exe в C:\Windows\system32\drivers\ и перезагружает компьютер

    2. Рассмотрим теперь ручное восстановление/копирование файла

    • для начала всё же отключим аваст (см. выше 3-ий пункт » если у вас стоит …»)
    • файл tcpip.sys можно скопировать из папки C:\Windows\system32\dllcache , но возможно аваст его то же удалил, тогда можно взять загрузочный CD/DVD/USB диск и там найти этот файл в …\I386\TCPIP.SY_ . Так же файл можно взять с рабочей системы. Но если взять этот файл вам не откуда, тогда вот ссылка для SP3 (если у вас SP2, то можете попросить) tcpip.sys
    • перезагрузите компьютер
    • проверьте работоспособность сети/интернета, если работает, тогда обновите аваст и запустите аваст (см. последний пункт 1-го способа)

    3. Если не помогли предыдущие способы, то скорее всего виноват не аваст. Проверьте, существует ли файл C:\windows\inf\nettcpip.inf , если существует, тогда приступайте к следующему способу. Если файла нет, тогда его нужно скопировать с рабочей системы, нет рабочей системы? Не беда, скачайте отсюда nettcpip.inf

    4. Переустановка стека TCP/IP используя Microsoft Fix it 50199 зеркало

    5. Можно попробовать утилиту TCPIP.Sys RestoreTool от фирмы UnHackMe , этой утилитой я не пользовался, но по описанию она должна переустанавливать стек TCP/IP в операционных системах: Windows 2000/XP/Vista/Seven/8 32 и 64-бит

    6. Сброс настроек стека TCP/IP вручную. На сайте Microsoft в статье kb299357 написано, что для переустановки достаточно выполнить выполнить всего одну команду в командной строке:

    • запустите cmd
    • выполните netsh int ip reset resetlog.txt
    • перезагрузите компьютер

    7. А теперь самое сложное переустановка стека TCP/IP в windows XP вручную.

    • Загрузите windows в Безопасный режим , то есть включаете компьютер и многократно нажимайте на F8 пока не появится меню загрузки windows, выберите Безопасный режим
    • Зайдите в реестр ( ПускВыполнитьregeditOK или Win + R )
    • Удалите два ключа и выйдите из реестра:

    Отказ в обслуживании

    Название этих атак хорошо отражает их суть, поскольку результатом данных атак является недоступность того или иного сервиса (определенного приложения) или целевой машины. Мы рассмотрим два типа отказа в обслуживании: один, основанный на ошибке в приложении, и другой, основанный на плохой реализации или уязвимости протокола.

    Отказ в обслуживании приложения

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

    Сетевой отказ в обслуживании

    Существует несколько типов атак «отказ в обслуживании», основывающихся на особенностях стека протоколов TCP/IP.

    SYN-наводнение

    Мы уже рассматривали механизм установления TCP-соединения (механизм тройного квитирования). SYN-наводнение использует этот механизм. Как вы помните, есть три состояния: посылка SYN-пакета, получение пакета SYN-ACK и посылка ACK-пакета. Идея атаки состоит в создании большого количества не до конца установленных TCP-соединений. Для реализации этого, злоумышленник посылает множество запросов на установление соединения (пакеты, с выставленным флагом SYN), целевая машина отвечает пакетами SYN-ACK. Злоумышленник же не завершает процесс установки соединения, а оставляет их в полу-открытом состоянии. Следовательно, для каждого полученного SYN-пакета сервер выделяет ресурсы и вскоре они исчерпываются. В результате, новые соединения не могут быть открыты. Этот тип отказа в обслуживании направлен только на целевую машину.

    Для реализации атаки SYN-наводнения злоумышленник может использовать программу synk4, передавая ей в качестве параметра целевой хост, порт и случайный адрес источника. Последнее затрудняет определение машины злоумышленника.

    UDP-наводнение

    Этот тип атаки «отказ в обслуживании» использует бессеансовый режим протокола UDP. Злоумышленник генерирует большое количество UDP-пакетов («шторм UDP-пакетов») направленных на одну или две машины. В результате происходит перегрузка сети и целевых машин. Эффективность данной атаки особенно высокая, поскольку UDP-трафик приоритетнее TCP-трафика. В протоколе TCP есть механизмы предотвращения перегрузок, если подтверждения приема пакетов приходят с значительной задержкой, передающая сторона замедляет скорость передачи TCP-пакетов. В протоколе UDP такой механизм отсутствует, и после начала атаки, UDP-трафик быстро захватит всю доступную полосу пропускания, и TCP-трафику останется лишь малая ее часть.

    Наиболее известный пример UDP-наводнения это атака на сервис chargen . Реализация этой атаки проста: достаточно установить связь между сервисами chargen на одной машине и сервисом echo на другой. Сервис chargen генерирует символы, а сервис echo дублирует полученные данные. Злоумышленник посылает UDP-пакеты на порт 19 ( chargen ) одной из машин-жертв, подделывая IP-адрес и порт источника. В данном случае, портом источника будет UDP-порт 7 ( echo ). Атака UDP-наводнение приводит к перегрузке сети на отрезке между двумя машинами. В результате, пострадать может вся сеть.

    Пакетная фрагментация

    Отказ в обслуживании, достигаемый с помощью пакетной фрагментации использует уязвимости некоторых стеков TCP/IP, связанных с дефрагментацией пакетов (сборкой IP-фрагментов).

    Известная атака, использующая этот подход — это Teardrop. Фрагментарное смещение второго сегмента меньше размера первого сегмента. Это означает, что при сборке фрагментов первый сегмент должен будет содержать данные второго сегмента, происходит перекрытие фрагментов. Во время сборки таких пакетов, некоторые системы не могут обработать сложившуюся ситуацию, что приводит к отказу в обслуживании. Существуют разные варианты этой атаки, например bonk, boink и newtear. Атака отказ в обслуживании «пинг смерти» использует некорректную обработку ICMP-фрагментов, посылая больше данных, чем максимальный размер IP-пакета. Разные типы атак «отказ в обслуживании» ведут к отказам целевой системы.

    Smurfing

    Данная атака использует ICMP-протокол. При посылке ping-пакета (сообщение ICMP ECHO) по широковещательному адресу (например, 10.255.255.255), он доставляется каждой машине в этой сети. Принцип атаки заключается в посылке пакета ICMP ECHO REQUEST с адресом-источником машины-жертвы. Злоумышленник шлет постоянный поток ping-пакетов по сетевому широковещательному адресу. Все машины, получив запрос, отвечают источнику пакетом ICMP ECHO REPLY. Соответственно, размер ответного потока пакетов возрастает в пропорциональное количеству хостов число раз. В результате, вся сеть подвергается отказу в обслуживании из-за перегрузки.

    Распределенная атака типа «отказ в обслуживании»

    Распределенная атака «отказ в обслуживании» перегружает целевую сеть или систему. Идея атаки, заключается в использовании разных источников (демонов) для атаки, и «владельцев» для управления. Наиболее известные утилиты организации DDoS ( распределенный отказ в обслуживании, Distributed Denial of Service ) — это Tribal Flood Network (TFN), TFN2K, Trinoo и Stacheldraht. На рисунке 13 приведен пример организации DDoS:

    Pиc.13: Распределенная атака «отказ в обслуживании»

    Злоумышленник использует «хозяинов» (masters) для управления источниками. Очевидно, что ему необходимо подключится (TCP) к «хозяинам» для того, чтобы их настроить и приготовить атаку. «Хозяева» лишь пересылают команды источникам по протоколу UDP. Без «хозяев», злоумышленнику пришлось бы устанавливать соединение с каждым из источников. Таким образом, происхождение атаки можно было бы легко обнаружить, а реализация ее занимала бы больше времени.

    Каждый источник обменивается с «хозяином» специфическими сообщениями. В зависимости от используемых утилит, общение может быть с использованием механизма авторизации и/или шифрования. Для установки источников и «хозяев», злоумышленник использует известные уязвимости (переполнение буфера таких сервисов, как RPC, FTP, и т.п.). Сама же атака являет собой либо SYN-наводнение, либо Smurf и приводит к отказу в обслуживании целевой сети или системы.

    Если Вы не нашли что искали, то рекомендую воспользоваться поиском по сайту:

    Атаки типа «отказ в обслуживании» (DoS) и «распределенный отказ в обслуживании» (DDoS)

    На сегодняшний день DDoS-атаки являются одними из самых опасных с точки зрения последствий.

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

    Чем же принципиально отличаются DoS и DDoS от других сетевых атак?

    Наверное тем, что цели таких атак не сводятся к получению тотального доступа к вашей сети или разведыванию какой-либо конфиденциальной информации. Нападения подобного рода используются в первую очередь для подрыва нормального функционала системы (это как раз тот случай, когда можно говорить о «нарушении доступности») за счет обработки пакетов или траты системных ресурсов.

    Подобные нападения имеют несколько разновидностей:

    • UDP flood представляет собой атаку, при которой на определенный адрес системымишени осуществляется отправка множества пакетов UDP (User Datagram Protocol – дополнительный компонент протокола TCP, поддерживающий выполняющуюся без подключений службу датаграмм, не гарантирующую ни доставку, ни правильную последовательность доставленных пакетов). В настоящее время подобный вид атак применяется все реже: особенностью UDP-отправителей является возможность их легкого обнаружения, что связано с отсутствием шифрования протоколов TCP и UDP на уровне взаимодействия управляющего атакой и машинами-зомби.
    • ICMP flood – атака посредством ICMP-протокола (Internet Control Message Protocol – обязательный управляющий протокол в наборе протоколов TCP/IP, сообщающий об ошибках и обеспечивающий связь между узлами сети. Именно протокол ICMP используется программой Ping для обнаружения и устранения неполадок TCP/IP).
    • Smurf. Продолжая экскурс по ICMP, более чем уместно упомянуть о так называемой атаке Smurf, представляющей собой пинг-запросы ICMP по адресу направленной широковещательной рассылки с использованием в пакетах этого запроса фальшивого адреса источника. В основе Smurf-атаки стоит использование Smurf-пинг-запросов по адресу направленной широковещательной рассылки. Используемый в пакетах этого запроса фальсифицированный адрес источника совпадает с адресом атакуемого. Системы, получившие направленный широковещательный пинг-запрос, как им и положено, исправно на него отвечают (естественно, тому, от кого пришел запрос). Результатом такого ответа является затопление атакуемого большим количеством сетевых пакетов, что, в конечном счете, приводит к отказу в обслуживании.
    • TCP SYN Flood имеет место, в случае если клиент пытается установить TCP-соединение с сервером, что требует обмена определенной последовательностью сообщений. Сначала клиентская система посылает SYN-пакет на сервер. После этого сервер подтверждает получение SYN-пакета, отсылая SYN-ACK-сообщение клиенту. Затем клиент завершает установку соединения, отвечая сообщением ACK, и затем снова должен произойти обмен данными. В точке, где система сервера послала подтверждение (SYN-ACK) назад клиенту, но еще не получила сообщения ACK, устанавливается полуоткрытое соединение. «Фишка» в том, что параметры, касающиеся всех ждущих обработки соединений, располагаются в оперативной памяти сервера, которая не безразмерна, разумеется. Если преднамеренно создать большое количество частично открытых соединений, то память переполнится, и система подвиснет.
    • Ping of Death. Атаки Ping of Death заставляют системы реагировать непредсказуемым образом при получении слишком больших IP-пакетов. TCP/IP поддерживает максимальный размер пакета в 65 Кбайт (как минимум 20 байт информации в IP-заголовке, некоторое количество дополнительной информации и остальная часть пакета, содержащая основные данные). Атаки Ping of Death могут вызвать крушение, зависание и перезагрузку системы.
    • Tribe Flood Network (TFN) и Tribe Flood Network 2000 (TFN2K) являются распределенными инструментальными средствами, обычно запускающими скоординированные DoS-атаки из многих источников на одну или несколько целей. Использование TFN-атаки дает возможность генерировать пакеты с фальшивыми IP-адресами источника. Механизм атаки приблизительно таков: злонамеренный пользователь посылает с главного компьютера команды нападения на список TFN-серверов или демонов. Затем демоны генерируют указанный тип DoS-атаки на один или несколько IP-адресов жертв. IP-адреса и порты источника атаки могут изменяться совершенно случайным образом, как и размеры пакетов. Высокая эффективность современных DDoS-атак достигается путем модификации и комбинирования отдельных ее видов. Уже упомянутые TFN и TFN2K позволяют одновременно инициировать атаки нескольких типов: Smurf, UDP flood, ICMP flood и TCP SYN flood, – что делает их мощным инструментом для подобных задач. Пересылка команд и параметров при этом умело замаскирована в передаваемых данных, чтобы не вызвать подозрений у защитного ПО. Как средства организации распределенных атак TFN и TFN2K относительно сложны и требуют от атакующего намного более высокой квалификации, чем в других случаях, но и практическая эффективность их намного выше.
    • Stacheldracht. Ярчайшим представителем средств организации DoS-атак нового поколения является Stacheldracht (дословно «колючая проволока»). Stacheldraht объединяет в себе особенности некоторых DoS-атак, в том числе TFN, шифрование связи между нападающим и главными серверами Stacheldraht и автоматическое обновление агентов. Начальный этап атаки включает активное массированное проникновение в большое количество систем для последующего использования их при атаке. Затем следует заключительный этап, в ходе которого «порабощенные» системы используются для атаки на один или несколько объектов.
    • IP spoofing (подмена IP-адресов) атаки – это не разновидность DoS, но, тем не менее, атаки подобного рода широко используются, в случае если необходимо скрыть IP, что имеет место при организации любой DDoS.
    • MAC spoofing. атаки. Применяются для фальсификации MAC-адреса. Атака подобного рода проводится тогда, когда необходимо, чтобы машину взломщика приняли за доверенную машину, в случае если доступ закрыт посредством фильтрации MAC-адресов. Остановимся на технологии подробнее.

    В пределах локальной сети каждая сетевая карта маркируется уникальным MAC-адресом – 12-значным шестнадцатеричным числом. Прежде чем отправить пакет в локальную сеть, драйвер сетевой карты определяет по IP-адресу точки назначения физический адрес сетевой карты компьютера-адресата и помечает пакет соответствующим MAC. На принимающей стороне сетевая карта, получившая пакет со своим MAC-адресом, пропускает его, направляя по цепочке «драйвер – операционная система – приложение». Взаимодействие машин в сети на физическом уровне обслуживается протоколом ARP, который представляет собой протокол из набора протоколов TCP/IP, обеспечивающий сопоставление IP-адресов с адресами MAC для пакетов IP. В случае если машина отправляет пакет в пределах подсети, для сопоставления и привязки MAC/IP служит ARP-таблица. При отсутствии записей в ARP-таблице в ход идут данные ARP-кэша. И только в крайнем случае, когда данные нигде не найдены, осуществляется широковещательный ARP-запрос по адресу ff:ff:ff:ff:ff:ff (значит, всем).

    Особенности протокола ARP таковы, что возможна практически беспрепятственная подмена истинных соответствий в ARP-хэше. Для этого может быть использовано специализированное программное обеспечение вроде SMAC или MAC SPOOFER 2006 (рисунок ниже).

    • Password attacks (атаки для взлома паролей) могут использовать различные методы: лобовая атака, или Brute Force – так называемый грубый перебор паролей. «Брутфорс» – атаки имеют место в том случае, если существует потенциальная возможность множественных попыток аутентификации: электронные ящики, учетные записи FTP, SAM-файлы, PWL-файлы, UIN и т. д. В ходе атаки последовательно перебираются все возможные комбинации символов, сочетание которых может оказаться верным. Процесс такого перебора автоматизирован и осуществляется с помощью специализированного программного обеспечения.
    • Packet sniffers – приложение, которое использует сетевой адаптер в «беспорядочном режиме» (когда сетевой адаптер посылает на обработку все пакеты, физически полученные по сети), чтобы захватить все сетевые пакеты, посланные через определенный домен. Снифферы пакетов используются легально в сетях для анализа трафика и поиска неисправностей.

    Однако, так как некоторые сетевые приложения посылают данные открытым текстом (telnet, FTP, SMTP, POP3 и т. д.), сниффинг пакетов может предоставить даже критически важную информацию, например имена пользователей и пароли.

    Мастер Йода рекомендует:  Путь к мастерству создаём веб-карту на Python
    Добавить комментарий