риск, связанный с использованием winPcap вместо сокета - PullRequest
Новая
       12

риск, связанный с использованием winPcap вместо сокета

0 голосов
/ 07 июля 2010

То, что я прочитал до сих пор, winPcap позволяет обойти ОС и обойти обработку приложений и транспортного уровня для TCP и обеспечивает прямой доступ к канальному уровню.

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

Влечет ли какой-либо риск обход ОС и, как я понимаю, прикладной и транспортный уровни на моей стороне?* В качестве дополнительного вопроса, документация winpcap, которую я нашел до сих пор, говорит о том, как программно реализовать ее, но не рассказывает подробно, что она обходит и как она это делает.Любая ссылка на это будет полезна.

Кроме того, я хотел бы знать, использует ли кто-нибудь winpcap для каких-либо целей, кроме перехвата сети для целей мониторинга и MSN.

1 Ответ

1 голос
/ 08 июля 2010

Конечно, существует множество рисков:

  • Операционная система не будет знать о ваших TCP-соединениях, находящихся в частном управлении, поэтому она не будет знать, что выбранный вами порт (ы) используется / используется. Это означает, что он может попытаться использовать тот же порт для подключения другого приложения, что приведет к хаосу.
  • ОС не будет знать о ваших TCP-соединениях, находящихся в частном управлении, поэтому, если вы не запретите ей видеть эти пакеты, она будет отправлять RST-пакеты для сброса явно фиктивного соединения.
  • Ваше приложение не будет автоматически уведомлено об изменениях соответствующих данных, управляемых ОС, настроенных IP-адресов и таблиц маршрутизации. Скорее всего, вам придется опросить обновления.
  • Правильно реализовать протокол TCP нетривиально. Большинство реализаций, даже очень хорошо используемых, имели неактивные ошибки, которые не были обнаружены в течение лет . Не вся необходимая информация также содержится в RFC; Есть места, где установленная практика отличается от документированного поведения, как правило, по уважительной причине. В современных стеках TCP также имеется множество кода, специально предназначенного для исправления исторических ошибок в других стеках, и репликация всей этой работы непроста.
  • Существует значительный риск плохого взаимодействия со сторонним программным обеспечением сетевой безопасности, установленным на хосте, который будет ожидать, что все соединения TCP будут установлены через ОС.

Мне кажется, что это кошмар поддержки.

...