поведение при прослушивании (winsock2) в отношении сканирования портов (Syn Scan)

Question

Должно ли серверное приложение, которое прослушивает порт, способно обнаруживать и записывать любую попытку подключения, выполненную с помощью Syn Scanning?

Тестовый сценарий

я написал окна программы, которые я просто назвал его «simpleServer.exe». Эта программа является просто симуляцией очень простого серверного приложения. Он прослушивает порт и ждет входящих сообщений. Слуховой сокет был определен как TCP Stream Socket. это все, что делает эта программа.

Я развертывал эту ту же программу на двух разных машинах, работающих на Windows 7 Professional 64bit. Эта машина будет выступать в качестве хоста. , и они размещены в одной и той же сети.

then, используя программу "nmap", Я использовал другую машину в той же сети, чтобы действовать как клиент. , используя параметр «-sS» на «nmap», я выполняю синхронизацию, в IP и порт прослушивающего SimpleServer на обоих компьютерах (по одной попытке за раз).

(обратите внимание, что 2 хозяева уже «Wireshark» началась, и осуществляет мониторинг по TCP-пакетов с IP клиента и слушающего порта.)

В записи «WIRESHARK», как на машине, я видел ожидаемый пакет tcp для Syn Scan:

client ----(SYN)----> host 

client <--(SYN/ACK)-- host 

client ----(RST)----> host 

вышеуказанный пакет обмена предполагает, что соединение не установлено.

Но на «simpleServer.exe» только одно из них имело «новое входящее соединение», напечатанное в журналах, в то время как другой экземпляр не был уведомлен о каком-либо новом входящем соединении, поэтому никаких журналов вообще не было.

фрагменты кода

// socket bind and listen was done above this loop 
while(TRUE) 
{ 
    sClient=accept(sListen,(SOCKADDR*)&remoteAddr,&nAddrLen); 
    if(sClient == INVALID_SOCKET) 
    { 
     printf("Failed accept()"); 
     continue; 
    } 
    dwSockOpt (sListen); 
    printf ("recv a connection: %s\n", inet_ntoa(remoteAddr.sin_addr)); 

    closesocket(sClient); 
} 

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

Дальнейшее расследование

я имел также положить getsockopt() в «SimpleServer» сразу после того, как она вступила в состояние прослушивания, чтобы проверить различия опции SOL_SOCKET ОБА для прослушивания сокета.

Одна заметная разница между двумя хостами, является SO_MAX_MSG_SIZE. Хост, который обнаруживает входящее соединение, имеет значение Hex 0x3FFFFFFF (1073741823), а другое, у которого нет журналов, равно 0xFFFFFFFF (-1). не уверен, что это связано или нет, но я просто рассылал все различия, которые могут возникнуть в моей тестовой среде. другое значение SOL_SOCKET более или менее одинаковое.

примечание стороны: я тестировал на другой машине, которая покрывает другой профессионал Windows 7, сервер Windows 2008 r2, сервер Windows 2003. Я не уверен, совпадение или нет, но машина, которая имеет SO_MAX_MSG_SIZE == -1 , все они не обнаружили соединение Syn Scanning. но, возможно, это просто совпадение. Мне нечего доказывать.

Помощь, что мне нужно

• почему различное поведение от 2 же одного и того же приложения на другой машине с той же ОС?
• Что определяет значение SO_MAX_MSG_SIZE? учитывая две одинаковые ОС, но имеющие 2 разных значения.

Answer 1

Если соединение не установлено, accept() никогда не вернется. Это составляет 90% вашего вопроса.

Единственное объяснение для сообщения «новое входящее соединение» (или сообщение «recv a connection» или что-то еще) - это что-то еще.

SO_MAX_MSG_SIZE не имеет значения для сокета TCP, не говоря уже о прослушиваемом TCP-сокете. Так что любая вариация, которую вы испытали, бессмысленна.