SYN cookie — SYN cookies
SYN cookie — это метод, используемый для защиты от атак IP Spoofing. Основной изобретатель метода Дэниел Дж. Бернштейн определяет файлы cookie SYN как «конкретный выбор исходных порядковых номеров TCP серверами TCP». В частности, использование файлов cookie SYN позволяет серверу избегать разрыва соединений при заполнении очереди SYN. Вместо сохранения дополнительных соединений запись очереди SYN кодируется в порядковый номер, отправленный в ответе SYN + ACK. Если сервер затем получает последующий ответ ACK от клиента с увеличенным порядковым номером, сервер может восстановить запись в очереди SYN, используя информацию, закодированную в порядковом номере TCP, и продолжить подключение как обычно.
- 1 Реализация
- 2 Недостатки
- 3 Соображения безопасности
- 4 История
- 5 См. Также
- 6 Ссылки
Реализация
Чтобы инициировать TCP-соединение, клиент отправляет на сервер пакет TCP SYN. В ответ сервер отправляет клиенту пакет TCP SYN + ACK. Одно из значений в этом пакете — это порядковый номер, который используется TCP для повторной сборки потока данных. Согласно спецификации TCP, этот первый порядковый номер, отправленный конечной точкой, может быть любым значением, определенным этой конечной точкой. Файлы cookie SYN — это начальные порядковые номера, которые тщательно построены в соответствии со следующими правилами:
- пусть t будет медленно увеличивающейся отметкой времени (обычно time()логически сдвинутой вправо 6 позиций, что дает разрешение 64 секунды)
- пусть m будет значением максимального размера сегмента (MSS), в котором сервер будет хранить запись очереди SYN
- пусть s будет результатом криптографической хеш-функции, вычисленной по IP-адресу сервера и номеру порта, IP-адресу клиента и номеру порта, и значению т . Возвращаемое значение s должно быть 24-битным значением.
Начальный порядковый номер TCP, то есть файл cookie SYN, вычисляется следующим образом:
- Верхние 5 битов: tmod 32
- Средние 3 бита: закодированное значение, представляющее m
- Нижние 24 бита: s
(Примечание: поскольку m должен быть закодирован с использованием 3-х битов, сервер может отправлять до 8 уникальных значений для m когда используются файлы cookie SYN.)
Когда клиент отправляет обратно пакет TCP ACK серверу в ответ на пакет SYN + ACK сервера, клиент должен (согласно протоколу TCP spec) используйте n + 1 в номере подтверждения пакета, где n — начальный порядковый номер, отправленный сервером. Затем сервер вычитает 1 из номера подтверждения, чтобы отобразить SYN cookie, отправленный клиенту.
Затем сервер выполняет следующие операции.
- Проверяет значение t на текущее время, чтобы узнать, истек ли время соединения.
- Повторно вычисляет s, чтобы определить, действительно ли это действительный SYN cookie.
- Декодирует значение m из 3-битной кодировки в файле cookie SYN, которое затем можно использовать для восстановления записи очереди SYN.
С этого момента подключение продолжается как обычно.
Недостатки
Использование файлов cookie SYN не нарушает никаких спецификаций протокола и, следовательно, должно быть совместимо со всеми реализациями TCP. Однако есть два предупреждения, которые вступают в силу при использовании файлов cookie SYN. Во-первых, сервер ограничен только 8 уникальными значениями MSS, так как это все, что можно закодировать в 3 бита. Во-вторых, сервер должен отклонить все параметры TCP (такие как большие окна или временные метки), потому что сервер отбрасывает запись очереди SYN, в которой в противном случае сохранялась бы эта информация.. Наконец, файлы cookie SYN увеличивают нагрузку на ресурсы сервера. Шифрование ответов требует больших вычислительных ресурсов. Файл cookie SYN не снижает трафик, что делает его неэффективным против атак SYN-лавинной рассылки, нацеленных на полосу пропускания в качестве вектора атаки.
Хотя эти ограничения обязательно приводят к неоптимальному опыту, их эффект редко замечается клиентами, потому что они применяются только тогда, когда они атакованы. В такой ситуации потеря опций TCP для сохранения соединения обычно считается разумным компромиссом.
Проблема возникает, когда пакет ACK завершения соединения, отправленный клиентом, потерян, а протокол прикладного уровня требует, чтобы сервер говорил первым (SMTP и SSH два примера). В этом случае клиент предполагает, что соединение было установлено успешно, и ждет, пока сервер отправит баннер своего протокола или повторно отправит пакет SYN + ACK; однако сервер не знает о сеансе и не будет повторно отправлять SYN + ACK, поскольку он отбросил запись очереди невыполненных работ, которая позволила бы ему это сделать. В конце концов, клиент прервет соединение из-за тайм-аута уровня приложения, но это может занять относительно много времени.
В 2008 году в версии 2.6.26 ядра Linux добавлена ограниченная поддержка параметров TCP путем их кодирования. в метку времени.
Стандарт TCP Cookie Transactions (TCPCT) был разработан, чтобы преодолеть эти недостатки SYN cookie и улучшить его по нескольким аспектам. В отличие от файлов cookie SYN, TCPCT является расширением TCP и требует поддержки с обеих конечных точек. В 2016 г. RFC 7805 перешел в статус «Исторический».
Соображения безопасности
Простые брандмауэры, которые настроены на разрешение всех исходящих подключений но чтобы ограничить, какие порты может достигать входящее соединение (например, разрешить входящие соединения с веб-сервером на порт 80, но ограничить все остальные порты), работайте, блокируя только входящие SYN-запросы к нежелательным портам. Если используются файлы cookie SYN, следует позаботиться о том, чтобы злоумышленник не смог обойти такой брандмауэр, создав вместо этого ACK, пробуя случайные порядковые номера, пока один из них не будет принят. Файлы cookie SYN следует включать и выключать для каждого порта, чтобы файлы cookie SYN, включенные на общедоступном порту, не распознавались на непубличном порту. Первоначальная реализация ядра Linux неправильно понимала эту часть описания Бернштейна и использовала единственную глобальную переменную для включения файлов cookie SYN для всех портов; на это указал студент-исследователь и впоследствии зафиксировал в CVE — 2001-0851.
История
Метод был создан Дэниелом Дж. Бернстайном и Эрика Шенка в сентябре 1996 года. Первая реализация (для SunOS ) была выпущена Джеффом Вейсбергом месяц спустя, а Эрик Шенк выпустил свою реализацию Linux в феврале 1997 года. FreeBSD реализует синхронизирующие файлы, начиная с FreeBSD 4.5 (январь 2002 г.).
См. Также
- SYN flood
- IP Spoofing
- TCP Cookie Transactions
Ссылки
- D. Собственное объяснение SYN cookie Дж. Бернштейном
- ^[1], cr.yp.to сентябрь 1996
- ^Андраш Корн, Механизмы защиты от сетевых атак и червей (pdf), 2011
- ^Патрик МакМанус, Улучшение файлов cookie, lwn.net апрель 2008 г.
- ^Клин, Энди (31 мая 1999 г.). «Реализация Syncookies для ядра Linux (версия 2.2.9)». static unsigned long tcp_lastsynq_overflow
- ^Браун, Сайлас С. (15 октября 2001 г.). «Сеть Linux: ошибка безопасности в файлах SYN cookie». Решение (как указал DJ Bernstein в частной беседе в ответ на вышеизложенное) состоит в том, чтобы сделать переменную tcp_lastsynq_overflow локальной для каждого порта прослушивания, а не глобальной.
- ^»Ядро Linux, использующее файлы cookie синхронизации, может позволить злоумышленнику обойти фильтрацию «. 2001. Архивировано из оригинала 13 апреля 2013 года. Проверено 17 марта 2013 г.
- ^http://man.freebsd.org/syncookies
Syn cookies что это
Поздравляем Вас с наступающим Новым годом и желаем Вам успехов и свершений.
| Новая версия iptables Публикация 28 Сен 2006 (Чт) в 22:13:22 (1935 просм.) Тема Контроль сетевого трафика |
| Сегодня была анонсирована новая версия iptables 1.3.6, в которой исправлены обнаруженные в iptables 1.3.5 ошибки и добавлен целый ряд новых возможностей. |
Примечание: Для загрузки исходного кода используйте ссылку
| 25 лет стандартам для протоколов TCP и IP Публикация 26 Сен 2006 (Вт) в 19:05:28 (1509 просм.) Тема |
| 25 лет назад, в сентябре 1981 г., были стандартизованы протоколы IP (RFC 791) и TCP (RFC 793). |
Примечание: Узнать больше об истории создания протколов Internet вы можете из статью, опубликованной на сайте Internet Society.
| Осенний фестиваль курсов по информационной безопасности Публикация 31 Авг 2006 (Чт) в 20:50:03 (1396 просм.) Тема Вопросы безопасности |
| Учебный центр NTC ╚Корпорации ЮНИ╩ открыл учебный год ╚Фестивалем курсов по информационной безопасности╩. |
Образовательный проект Учебного центра NTC объединит профессиональные учебные курсы партнеров NTC, посвященные теме информационной безопасности.
Примечание: Для регистрации на заинтересовавшие Вас курсы используйте ссылку.
| Обзоры : Новая версия Snort Публикация 30 Авг 2006 (Ср) в 20:35:39 (1559 просм.) Тема Детектирование попыток вторжения в сеть |
| 22 августа выпущена новая версия Snort — популярной системы детектирования попыток вторжения и анализа трафика. |
Примечание: Для загрузки исходного кода программы используйте ссылку.
| Уязвимость в ядре Linux Публикация 08 Июн 2006 (Чт) в 16:32:10 (1927 просм.) Тема Вопросы безопасности |
| На сайте Beyond Security 6 июня было опубликовано сообщение о наличии уязвимости в системе фильтрации пакетов netfilter ядра Linux (модуль ip_nat_snmp_basic). Обнаруженная уязвимость связана с некорректной работой с памятью и может приводить к возможности организации DoS-атаки против систем, на которых используется трансляция адресов для трафика SNMP через порты 161 и 162. Уязвимость существует в ядрах Linux вплоть до 2.16.17. В ядре версии 2.16.18 данная уязвимость устранена. |
Примечание: Информация CVE
CVE-2006-2444
Программа vconfig, разработанная Ben Greear , позволяет создавать и удалять устройства VLAN в системах Linux, ядро которых поддерживает виртуальные ЛВС. Устройства VLAN представляют собой виртуальные интерфейсы Ethernet, представляющие виртуальные сети в физической ЛВС.
Примечание: Описание программы основано на информации из руководства man (Ard van Breemen )
На конференции IEEE security and privacy, которая состоится 22 — 24 мая 2006 г. в Оклэнде Zvi Gutterman, Benny Pinkas и Tzachy Reinman выступят с результатами своих исследований генератора случайных чисел в ядре Linux, показавшего наличие «дыр» в генераторе.
Примечание: Более подробно о конференции можно узнать на сайте .
Предложено создать новую рабочую группу IETF в рамках направления Internet Area. Задачей группы является изучение вопросов передачи трафика IP через широкополосные сети радиодоступа IEEE 802.16. Группа пока не получила окончательного названия и носит временное имя 16ng.
Если у Вас еще нет учетной записи, Вы можете зарегистрироваться.
| Выбор категорий |
| · Все категории · Обзоры |
Защита от DDOS, включаем TCP SYN Cookie
Если ваш домен атакуют с помощью SYN атаки, которая является DoS атакой. Она потребляет ресурсы на сервере Linux. Злоумышленник начинает работу с подтверждения соединения TCP отправкой пакета SYN, а затем никогда не завершает процесса, чтобы открыть соединение.
Это приводит к массовым полуоткрытым соединениям. Ядро Linux может блокировать такие атаки легко. Делается это просто:
# sysctl -n net.ipv4.tcp_syncookies
Если же вам необходимо чтоб параметр оставался и после перезагрузки редактируем:
Sulich’s Blog
Большинство людей знает, насколько может быть проблематична защита от SYN-атак. Обычно используются несколько более или менее эффективных методов. Почти в каждом случае, основным решением является правильная фильтрация пакетов. В дополнение к созданию пакетных фильтров, администратором может быть выполнена модификация TCP/IP стека данной операционной системы. Данный метод – настройка TCP/IP стека в различных операционных системах, и будет описан ниже.
В то время как невозможно полностью предотвратить SYN атаки, настройка TCP/IP стека помогает уменьшить влияние этого вида атак, при этом все еще разрешая легальный клиентский трафик через сервер. Необходимо отметить, что некоторые SYN атаки не всегда пытаются “положить” серверы, вместо этого они пытаются потребить всю пропускную способность вашего Internet канала.
Что может сделать администратор, когда его серверы подвергаются классической (не использующей заполнения пропускной способности интернет-канала), SYN атаке? Одним из наиболее важных шагов является включение встроенных в операционную систему механизмов защиты, таких как SYN cookies или SynAttackProtect. Дополнительно, в некоторых случаях, необходима настройка параметров TCP/IP стека. Изменение заданных по умолчанию значений стековых переменных, является уже другим уровнем защиты и помогает нам лучше защитить наши хосты. В этой статье мы сконцентрируем наше внимание на:
Увеличении очереди полуоткрытых соединений (в состоянии SYNRECEIVED).
Уменьшении, в очереди, периода времени хранения незавершенных подключений в состоянии SYNRECEIVED.
Этот метод выполняется с помощью уменьшения времени первой повторной передачи пакета или уменьшения (вплоть до полного отключения) количества повторных передач пакета. Процесс повторной передачи пакета выполняется сервером, до получения от клиента ACK пакета. Пакет с флагом ACK завершает процесс установления соединения между сервером и клиентом.
Необходимо обратить внимание на то, что нападающий может посылать большее количество пакетов с флагом SYN, и тогда вышесказанные операции не смогут решить эту проблему. Однако их выполнение может увеличить вероятность создания полного подключения с легальными клиентами.
Также необходимо помнить, что модификация переменных, изменит режим работы стека TCP/IP. Так, после модификации, мы должны удостовериться, что сервер может должным образом связываться с другими хостами. Например, отключение повторных передач пакета в некоторых системах низкой пропускной способностью, может привести к отказу в работе при легальных запросах. В этой статье можно найти описание TCP/IP переменных для следующих операционных систем: Microsoft Windows 2000, RedHat Linux 7.3, Sun Solaris 8 и HP-UX 11.00.
Определения: SYN атака и SYN спуфинг.
SYN атака -это один из типов DDoS атак. Мы можем говорить, что хост жертвы подвергся SYN атаке, в случае, когда злоумышленник пытается создать огромное количество подключений в состоянии SYNRECEIVED до тех пор, пока не переполнится очередь соединений. Состояние SYN RECEIVED создается, когда хост жертвы получает запрос на подключение (пакет с набором флага SYN) и распределяет для этого некоторые ресурсы памяти. При SYNатаке создается такое количество полуоткрытых подключений, что система переполняется и больше не может обрабатывать поступающие запросы.
Для увеличения эффективности SYN атаки, злоумышленник использует фиктивные IP адреса в SYN пакетах. В этом случае хост жертвы не может быстро закончить процесс инициализации, потому что исходный IP адрес может быть недостижим. Эта злонамеренная операция называется SYN спуфингом.
Мы должны знать, что процесс создания полного подключения занимает некоторое время. Первоначально, после получения запроса на подключение (пакет с набором флага SYN), хост жертвы помещает это полуоткрытое соединений в очередь и посылает первый ответ (пакет с флагами SYN и ACK). Если жертва не получает ответ от удаленного хоста, то она повторно передает SYN+ACK пакеты, до тех пор, пока не наступит тайм-аут, а затем удаляет это полуоткрытое соединение из очереди. В некоторых операционных системах этот процесс, для каждого отдельного SYN запроса, может занимать приблизительно 3 минуты! В этом документе Вы узнаете, как можно изменить эту закономерность. Другой, не менее важной информацией, которой Вы должны владеть является то, что операционная система может обрабатывать только определенное количество полуоткрытых подключений в очереди. Это количество управляется размером очереди соединений. Например, заданный по умолчанию размер очереди в RedHat 7.3 – 256, а в Windows 2000 Professional – 100. Когда размер очереди достигнет этого размера, система больше не будет принимать поступающие запросы.
Обнаружение SYN атак
Обнаружить SYN атаку очень легко. Команда netstat показывает нам количество подключений находящихся в полуоткрытом состоянии. Полуоткрытое состояние описано как SYN_RECEIVED в Windows и как SYN_RECV в Unix системах.
# netstat -n -p TCP tcp 0 0 10.100.0.200:21 237.177.154.8:25882 SYN_RECV - tcp 0 0 10.100.0.200:21 236.15.133.204:2577 SYN_RECV - tcp 0 0 10.100.0.200:21 127.160.6.129:51748 SYN_RECV - tcp 0 0 10.100.0.200:21 230.220.13.25:47393 SYN_RECV - tcp 0 0 10.100.0.200:21 227.200.204.182:60427 SYN_RECV - tcp 0 0 10.100.0.200:21 232.115.18.38:278 SYN_RECV - tcp 0 0 10.100.0.200:21 229.116.95.96:5122 SYN_RECV - tcp 0 0 10.100.0.200:21 236.219.139.207:49162 SYN_RECV - tcp 0 0 10.100.0.200:21 238.100.72.228:37899 SYN_RECV - .
Мы можем также подсчитать количество полуоткрытых подключений находящихся в очереди в настоящее время. В приведенном ниже примере, 769 подключений (для TELNET) находящихся в состоянии SYNRECEIVED сохраняются в очереди задач.
* netstat-n-p TCP | grep SYN_RECV | grep:23 | wc-l
769
Другой метод обнаружения SYN атак состоит в распечатке статистики TCP и просмотре параметров TCP, подсчитывающих количество отклоняемых запросов. Во время атаки значения этих параметров быстро возрастают.
В этом примере мы пронаблюдаем за значением параметра TcpHalfOpenDrop на системе SunSolaris.
* netstat-s-P tcp | grep tcpHalfOpenDrop
tcpHalfOpenDrop = 473
Важно обратить внимание на то, что каждый tcp порт имеет свою собственную очередь соединений, но только одна переменная стека tcp/IP управляет размером этой очереди для всех портов.
Очередь соединений
Очередь соединений – большая структура памяти, используемая для обработки поступающих пакетов с набором флага SYN до момента установления соединения между клиентом и сервером. Операционная система распределяет часть системной памяти для каждого поступающего соединения. Мы знаем, что каждый tcp порт может обрабатывать только определенное количество поступающих запросов. Очередь соединений управляет количеством полуоткрытых подключений, способных одновременно обрабатываться операционной системой. Когда количество поступающих соединений достигнет максимального уровня, все последующие запросы будут отклонены операционной системой.
Как упомянуто выше, обнаружение большого количества соединений в состоянии SYN RECEIVED скорее всего означает, что хост подвергся SYN атаке. Кроме того, исходные IP адреса, этих пакетов могут быть фиктивными. Для ограничения эффективности SYN атак мы должны включить некоторые встроенные защитные механизмы. Иногда мы также можем использовать методы типа увеличения размера очереди соединений и уменьшения времени хранения незавершенных соединений в распределяемой памяти (в очереди соединений).
Встроенные механизмы защиты
Операционная система: Windows 2000
Наиболее важным параметром в Windows 2000 и в Windows Server 2003 является параметр SynAttackProtect. Включение этого параметра позволяет операционной системе более эффективно обрабатывать поступающие соединения. Защита может быть установлена, путем добавления значения SynAttackProtect, типа DWORD, в следующий ключ системного реестра:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters В случае обнаружения SYN атаки, параметр SynAttackProtect изменяет режим работы стека TCP/IP, что позволяет операционной системе обрабатывать большее количество SYN запросов. Принцип работы заключается в отключении некоторые опций сокета, добавлении дополнительных задержек к показаниям соединения и изменении тайм-аута для запросов.
Когда значение SynAttackProtect равно 1, количество повторных передач уменьшено, а маршрутизация содержимого кеша отсрочена до создания соединения. Рекомендуемое значение SynAttackProtect – 2, при котором дополнительно задерживается признак соединения с Windows Socket до установления связи сервера с клиентом. В ходе нападения, лучшая производительность в обработке соединений достигается с помощью отключения нескольких параметров (эти параметры обычно используются системой в течение процесса создания новых соединений). Параметр TCPINITIALRTT, определяющий время первой перепередачи, больше не будет использоваться.
Как мы можем увидеть, включение параметра SynAttackProtect не изменяет режим работы стека TCP/IP до и при SYN атаке. Но даже при включенном параметре SynAttackProtect, операционная система может обрабатывать легальные поступающие соединения.
Операционная система автоматически включает защиту от SYNатак, когда обнаруживает превышение значений следующих трех параметров: TcpMaxHalfOpen, TcpMaxHalfOpenRetried и TcpMaxPortsExhausted.
Чтобы изменить значения этих параметров, сначала мы должны добавить их к тому же самому ключу системного реестра, как и в случае с SynAttackProtect.
Элемент системного реестра TcpMaxHalfOpen определяет максимальное количество состояний SYN RECEIVED, которые могут быть одновременно обработаны, прежде чем сработает SYN защита. Рекомендуемое значение этого параметра – 100 для Windows 2000 Server и 500 для Windows 2000 Advanced Server.
TcpMaxHalfOpenRetried определяет максимальное количество полуоткрытых подключений, для которых операционная система выполнила по крайней мере одну повторную передачу, прежде, чем сработает SYN защита. Рекомендуемое значение – 80 для Windows 2000 Server, и 400 для Advanced Server.
Элемент системного реестра TcpMaxPortsExhausted определяет число отклоненных SYN запросов, после которого сработает защита от SYN атак. Рекомендованное значение – 5.
Операционная система: LinuxRedHat
В RedHat, как и в других Linux системах, осуществлен механизм SYN cookies, который включается следующим способом:
* ECHO 1 >/proc/sys/net/ipv4/tcp_syncookies
Обратите внимание, что для того чтобы сделать это изменение постоянным, мы должны создать загрузочный файл, который будет присваивать значение этой переменной. Мы должны проделать ту же самую операцию и для других UNIX переменных, описанных в этой статье, потому что значения этих переменных после перезагрузки системы вернуться к прежним значениям.
Защита SYN cookies особенно полезна, в случае, когда система подверглась SYN атаке, а исходные IP адреса пакетов – фиктивные (SYN спуфинг). Этот механизм позволяет структурировать пакеты с набором флагов SYN и ACK, которые имеют специально обработанный “начальный номер последовательности” (ISN), называемый cookie. Значение cookie это не псевдослучайное число, сгенерированное системой, а результат действия хеш-функции. Это значение генерируется хеш-функцией в зависимости от следующей информации: IP-адрес источника, порт источника, IP адрес получателя, порт получателя плюс некоторые секретные значения. В ходе SYN атаки, когда заполняется очередь соединений, система вместо отклонения запроса, генерирует ответ, посылая клиенту пакет с cookie. Когда сервер получает пакет с набором флажка ACK (последняя стадия процесса установления соединения с клиентом), тогда он проверяет значение cookie. Если это значение правильно, то сервер создает подключение, даже в случае если нет никакого соответствующего элемента в очереди соединений. В этом случае мы знаем, что это легальное соединение, и что исходный IP адрес не фиктивный. Важно обратить внимание на то, что механизм работы SYN cookie, вообще не использует очередь соединений, так что теперь мы не должны изменять её размер. Более подробную информацию об использовании SYN cookies можно найти здесь.
Также необходимо обратить внимание на то, что механизм SYN cookies работает только когда опция CONFIG_SYNCOOKIES установлена в ходе компиляции ядра системы.
В следующем разделе будут описаны другие полезные методы защиты от SYN атак. Я хотел бы подчеркнуть, что при более сложных видах SYN атак, эти методы могут помочь, но не решить проблему.
Увеличение размера очереди соединений
При SYN атаке, мы можем изменить размер очереди задач для поддержки большего количества полуоткрытых соединений так, чтобы не отклонять доступ к серверу легальным клиентам. В некоторых операционных системах, размер очереди задач очень маленький, поэтому производители рекомендуют увеличение этого значения, в случае если система подверглась SYN атаке.
Увеличение размера очереди задач требует, чтобы система резервировала дополнительные ресурсы памяти для входящих соединений. Если в системе отсутствует достаточное количество свободной памяти для этой операции, то пострадает производительность системы. Также мы должны удостовериться, что сетевые приложения (Apache, IIS и т.д.) смогут принимать большее количество подключений.
Операционная система: Windows 2000
Кроме описанных выше переменных TcpMaxHalfOpen и TcpMaxHalfOpenRetried, в Windows 2000 количество полуоткрытых подключений может быть установлено через динамическую очередь соединений. Конфигурирование этой очереди выполняется через драйвер AFD.SYS. Этот драйвер используется для поддержки Windows Socket приложений (FTP, Telnet и т.д.). Для увеличения количества полуоткрытых соединений, AFD.SYS поддерживает четыре элемента системного реестра. Все эти значения расположены в следующем ключе системного реестра:
Значение системного реестра EnableDynamicBacklog – глобальный переключатель, включающий или выключающий динамическую очередь соединений. Значение 1 – включает динамическую очередь.
MinimumDynamicBacklog – управляет минимальным количеством свободных соединений, разрешенных на каждом отдельном TCP порте. Если количество свободных соединений снижается ниже этого значения, то дополнительные свободные соединения будут созданы автоматически. Рекомендованное значение 20.
Значение MaximumDynamicBacklog определяет сумму активных полуоткрытых соединений и максимального количества свободных соединений. Если это значение будет превышено, то система больше не будет создавать свободные соединения. Рекомендованное значение не должно превышать 20000.
Последний параметр DynamicBacklogGrowthDelta управляет количеством свободных соединений, создаваемых в случае необходимости. Рекомендуемое значение: 10.
Ниже расположена таблица, показывающая рекомендуемые значения для драйвера AFD.SYS:
Значение подключа реестра
Формат
Значение