В 2002-м году я начал работать по специальности (до этого, с 2001 работал программистом на С и Perl), в области ИБ, и первыми моими задачами были - администрирование систем ИБ и их использование (ссылки на мои переписки с форумов того времени, закешированные Всемирной паутиной, я давал в этой заметке). Одним из продуктов в области моей ответственности был ISS Internet Scanner (вот попалась древняя статья с описанием). Ставился IS на ОС Windows, в то время это была Windows 2000. Десктопная W2000 тогда не отличалась выдающейся стабильностью, а сканер был развернут у меня на сервере, к которому я подключался удаленно. В такой конфигурации было объяснимо мое желание пересадить IS на W2000 Server, однако общение с поддержкой ISS выявило пагубность этой моей идеи и, в некоторой степени, просветило меня в, казалось бы очевидном, вопросе отличия серверных и десктопных операционных систем. И отличия эти кроются в тонких настройках протокола TCP/IP, значительно влияющих на сетевую производительность ОС.
Если на пальцах, то на десктопе работают в основном клиентские приложения, которые инициируют соединения по сети с множеством серверов, тогда как для сервера ситуация ровно обратная: к его приложениям-listener-ам подключаются множество клиентских приложений. Таким образом, характер работы с сетью, т.е. работа протокола TCP, у десктопа и у сервера сильно отличаются. Отчасти, именно поэтому MS выпускала десктопные и серверные операционные системы, поскольку тонкие параметры сетевых протоколов в этих ОС настроены по-разному: оптимизированы под инициирование множества клиентских соединений или под обслуживание множества входящих подключений к серверному приложению. Подобные оптимизации, как будто, не дают значимого выигрыша в производительности, однако, на больших объемах это начинает иметь значение.
Если вернутся к IS, то характер работы сетевого сканера однозначно клиентский - он инициирует множество сетевых соединений с множеством хостов и портов. IS не умел работать асинхронно, как, например, masscan, однако, размещение именно на десктопной версии ОС давало лучшую производительность, в сравнении с серверной ОС на том же железе. В то время виртуализация только набирала обороты, поэтому мой IS размещался на одноюнитовом младшем сервере, куда с одинаковым успехом я мог установить как десктопную, так и серверную W2000.
Чтобы не быть голословным приведу некоторые примеры параметров TCP/IP (на примере параметров ядра Linux), которые можно тюнить для оптимизации работы ОС в режиме сервера (обслуживающего клиентские соединения) или клиента (подключающегося к множеству серверов). Для сервера: tcp_tw_reuse – позволяет переиспользовать TIME-WAIT сокеты для новых исходящих соединений; tcp_max_syn_backlog – размер очереди полуоткрытых (SYN) соединений; somaxconn – максимальная длина очереди принятых, но не обработанных соединений; tcp_syncookies – настройка синкуки (защита от старой атаки SYN-flood); tcp_fin_timeout – время ожидания перед закрытием соединения в состоянии FIN-WAIT-2; tcp_keepalive_time – интервал отправки keepalive-пакетов. Для клиента: tcp_slow_start_after_idle – отключает "медленный старт" после простоя; tcp_rmem и tcp_wmem – размеры буферов чтения/записи; tcp_congestion_control – алгоритм управления перегрузкой (например, cubic, bic); tcp_no_metrics_save – не сохранять метрики соединений после закрытия. Кроме того, можно потюнить: tcp_window_scaling – масштабирование окна для высокоскоростных сетей; tcp_timestamps – временные метки для RTT-расчётов и защиты от старых пакетов (RFC1323, и вот еще можно почитать); tcp_mtu_probing – автоматический поиск оптимального MTU. Описанные параметры в Linux настраиваются через sysctl и располагаются в /etc/sysctl.conf. В Windows тоже можно понастраивать эти же параметры, в реесте - HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. Если все коротко обобщить, то для сервера важны настройки очередей (somaxconn, tcp_max_syn_backlog) и управление TIME-WAIT (tcp_tw_reuse), а для клиента - оптимизации буферов (tcp_rmem, tcp_wmem) и алгоритмы перегрузки (tcp_congestion_control). Т.е. технически анализ перечисленных параметров позволит определить для какого режима работы, в качестве сервера или клиента, оптимизированы тонкие сетевые настройки ОС.
Если же есть возможность анализировать сетевые соединения, то, очевидно это тоже может быть значимым знанием для отличия сервера от десктопа. Если сетевой трафик в общей своей массе представляет собой исходящие сетевые соединения на разные хосты и порты, скорее всего, это клиентская рабочая станция. Если же мы наблюдаем множество входящих соединений - это сервер. Если мы наблюдаем сетевой трафик непосредственно с эндпоинта, то запущенные процессы можно сопоставить с входящими соединениями, и понять функцию сервера в сети. Если же мы смотрим просто сетевой трафик с сетевой IDS, в целом, тот же подход работает, поскольку если попытки сетевых соединений неуспешны, это тоже будет видно по трафику: если служба упала, ОС отправит RST+ACK (RFC792 и RFC1122), а в случае UDP - ICMP Port unreachable (те же RFC). Кстати, занимаясь мониторингом сети, я именно так и замечал, что у ИТ упала какая-то служба - куча RST или ICMP3:3. В локальных сетях быстрая диагностика очень важна, поэтому, как бы не рекомендовали книжки про ИБ, блокировать ICMP в локальных сетях я бы не рекомендовал, а то и traceroute работать не будет.
В общем, подытожим: серверы и десктопы совершенно по-разному используют сеть, для оптимизации производительности TCP/IP в ОС есть ряд параметров, конфигурация которых может с высокой уверенностью подтвердить основной режим работы ОС (если, конечно, админ вообще заморачивался оптимизацией). Кроме того, простой анализ сетевого трафика также однозначно определяет является ли хост главным образом сервером или десктопом.
