Где можно найти инфу пр сканирование при помощи SYN пакетов
или rfc документ по SYN пакетам.
Или на худой конец исходник проги сканирующей с помощью этих пакетов

Там вроде как концептуально все просто. Посылается TCP пакет с включенным SYN битом. Если в ответ приходит TCP пакет с включенными SYN и ACK битами, то порт открыт и слушает. Если приходит TCP пакет с включенным RST битом, то порт соответсвенно закрыт.

Если все действительно так и делать в лоб, то написание кода сводится к созданию link layer сокета, небольшой возней с TCP и IP заголовками, и sendto. Ну а потом recvfrom все пакеты пока не получим ответ на наш SYN пакет.

Не исключаю, что я в чем то неправ и там все намного сложнее

Kill_em_all
Дык а чего ? Курни libnet (сишная которая, не перловская, шарить в гугле или www.sf.net) и НОУ ПРОБЛЕМ Кажись под винду тож есть версия. Там на сколько помню надо проставлять :
IP адреса
TTL
Порты
TCP флаги.
Кажись все. Остальное сама поставит и чексум посчитает. Мне нравится.

Цитата

Если приходит TCP пакет с включенным RST битом, то порт соответсвенно закрыт

Для виндового компа, извиняюсь, не так . Там обратное. Если ACK пришел, то открыт. Ежели ничего не пришло - закрыт, вестимо. Есть еще пара вариантов как это дело тестить. Ну да ладно...

Цитата(dwr_budr @ 29.11.2005, 02:19)

Если все действительно так и делать в лоб, то написание кода сводится к созданию link layer сокета, небольшой возней с TCP и IP заголовками, и sendto. Ну а потом recvfrom все пакеты пока не получим ответ на наш SYN пакет

link layer сокет(в смысле)?Это ли не RAW-сокет?

Да, а можно ли подобным (или еще каким-нить способом) просканить UDP-порты?
Я посмотрю rfc по tcp, но если никого не затруднит выложить исходник с примером

Цитата(GrayCardinal @ 29.11.2005, 08:09)

Дык а чего ? Курни libnet (сишная которая, не перловская, шарить в гугле или www.sf.net) и НОУ ПРОБЛЕМ  Кажись под винду тож есть версия.

Это либа или dll?

Kill_em_all
RAW сокеты бывают разные.

socket(AF_INET, SOCK_RAW, PROTOCOL_XXX); Такой сокет предоставляет доступ к network layer'у. При этом далеко не любой входящий пакет ядро направит в такой сокет. К примеру IP пакеты в которых TCP или UDP пакеты в аткой сокет не попадут. А IP пакет с неизвестным содержимым - попадет. У Стивенса есть подробное описание какие пакеты в такой сокет попадут.

socket(PF_PACKET, SOCK_DGRAM, PROTOCOL_XXX); Такой сокет позволяет получить доступ к link layer'у. Вот из него уже можно получать все входящие пакеты. Как-то пробовал сварганить простой сниффер и как раз такой сокет использовал.

GrayCardinal
Очень интересная деталь про виндовую реализацию TCP 3 way handshake'а. Только напрашивается вопрос: нафига эти вариации? К примеру виндовый комп общается с линуксовым. При неудачном 3wh линуксовый комп шлет TCP пакет с RST флагом. А что винда? А винда его не ждет, и ежели такой пакет придет она его должна по идее проигнорировать. И как это называется?

Это сообщение отредактировал(а) dwr_budr - 29.11.2005, 13:32

Я к тому, что я написал сниффер, но использовал
socket(AF_INET, SOCK_RAW, IPPROTO_IP);
а потом
ioctlsocket(s, SIO_RCVALL, &flag);
и я получал и tcp и udp пакеты
Я никак не разберусь как разобрать tcp пакет
Не покажешь ли как собрать и разобрать в структуру?

Прикольная фича. А ты с такими опциями получал именно голые TCP и UDP пакеты или IP пакеты?

А сам TCP пакет разобрать вроде несложно. В netinit/tcp.h определена struct tcphdr. Так что читай в такую структуру заголовок, проверяй включены ли SYNACK/RST флаги и я буду стирать nmap

Это сообщение отредактировал(а) dwr_budr - 29.11.2005, 13:30

Цитата(dwr_budr @ 29.11.2005, 11:51)

socket(PF_PACKET, SOCK_DGRAM, PROTOCOL_XXX); Такой сокет позволяет получить доступ к link layer'у. Вот из него уже можно получать все входящие пакеты. Как-то пробовал сварганить простой сниффер и как раз такой сокет использовал.

А при этом не надо сокет переводить в неразборчивый режим?

И tcp.h у меня нету
Где ее можно взять(пишу я на VC++7)

Это сообщение отредактировал(а) Kill_em_all - 30.11.2005, 11:29

Цитата(dwr_budr @ 29.11.2005, 13:30)

Прикольная фича. А ты с такими опциями получал именно голые TCP и UDP пакеты или IP пакеты?

А при этом не надо сокет переводить в неразборчивый режим?(ioctlsocket(s, SIO_RCVALL, &fl));

Код

typedef struct _TCP  {     WORD  SrcPort;     WORD  DstPort;     DWORD SeqNum;     DWORD AckNum;     BYTE  DataOff;     BYTE  Flags;     WORD  Window;     WORD  Chksum;     WORD  UrgPtr; } TCP;

Надеюсь это та структура?

Если да то спасибо, вроде бы понял (хотя еще не написал сканер)

dwr_budr
Да фигня а не реализация. Хотя мелкомягких тоже можно понять. Тупой сканер вроде for () {connect} уже не включишь. Да и nmap в отсойнике Купить хостинг и сканить с него уже не прокатит. А что еще для жизни надо ? Правда тут же получите reflected syn flood, но про это они почему - то не думают

ЗЫ
Ты еще не стер nmap ? Стирай нафиг Подкинуть вещичку для линуха ?

Kill_em_all
Я так и не понял куда направлен вопрос про неразборчивый режим. Если это в тему о link layer сокете, то не надо, потому как он уже получает все пакеты. Хотя наверняка и его можно настроить разными способами. А какую структуру используют в винде я не знаю, но та которую ты показал выглядит как надо.

GrayCardinal
Не понял почему for(;;) connect() сканнер не прокатит. Я понимаю, что такой сканнер тормознутый, но это уже другой вопрос.

А по поводу виндовго 3wh. Все же ну очень бредовая реализация. Ты уверен что ничего не путаешь? Где ты о такой фиче вычитал? Вот ты говоришь что если порт закрыт - ничего не придет. Тем не менее ответ может не прити не только потому что порт закрыт , но еще и потому что пакет не дошел и в таком случае запрос надо повторить. Как понять что же произошло? В итоге даже если порт действительно закрыт винда снова будет пробовать посылать запрос?

Я вычитал ? Да нифига. Сам сидел и слал SYN на microsoft.com Собственноручно. Ни один RST не пришел. Зато SYN/ACK - как положено. По сети проверял - у меня только виндовые компы. Та же фичя. Мож сам попробовать.

Включаешь tcpdump -vvv
Далее
connect ()
SYN уйдет - RST будешь ждать вечность (или пока не надоест )

И connect () будет ждать. Ну и SYN повторять. Только у него RTO сумасшедший (60 мин, что ли последний ? )

ЗЫ
или в мире что-то поменялось пока я спал ?

GrayCardinal

Да проверил я это дело. tethereal + nc. Ты прав RST с виндовых машин не приходят (пробовал на ms.com и на одном компе дома), так же пробовал на Сане и Линуксе - RST приходит. Ну а интерес к вопросу лишь поднимается. Получается неудачный коннект к виндовой машине занимает в среднем больше времени, чем к машине с нормальной реализацией TCP? А Билли хитёр.

Пробовал nmap'ить майкрософтовский сайт. Так вот сканирование connect()'ом заняло 50 секунд. А сканирование SYN'ами 70 секунд.

PS Я тут подумал. Может это дело рук фаервола или еще чего нить что непосредственно попадается по пути? Видит что порт не открыт - вот и молчит в ответ. На твоих компах фаерволы были? На моем есть, но в данный момент нет возможность его отключить и проверить.

Это сообщение отредактировал(а) dwr_budr - 1.12.2005, 10:04

dwr_budr
Не-а. У меня без файрволчиков. И nmap с connect просто глохнет на первом же connect (хотя я, в основном, не nmap, а самопалкой, но смысл от этого не меняется). nmap - ить SYN'ами не пробовал. Однако той-же самопалкой сканер SYN'ами - не больше трех секунд для виндовой машины (если по локалке, на модеме дольше, конечно ). Там даже не надо проверять RST. Тупо включаешь tcpdump, посылаешь 65535 SYN. И получаешь столько-то ACK. Красиво так выходит. Было дело сидел радовался.

ЗЫ
Билли сам себе могилу роет. Шо будет если адрес подделать и рассылать SYN якобы с его адреса, а ? Кранты ему будет вот что

Это сообщение отредактировал(а) GrayCardinal - 1.12.2005, 12:39

Цитата(dwr_budr @ 30.11.2005, 23:23)

Не понял почему for(;;) connect() сканнер не прокатит. Я понимаю, что такой сканнер тормознутый, но это уже другой вопрос.

dwr_budr
Это смотря как его реализовать он тормознутый. У меня сканер 2000 портов сканит около пол минуты, а
весь диапазон от силы минут 15. А если еще пару дней посидеть и геморрой позарабатывать
разбиванием скана на 5-10 потоков, то вообще идеал (не беря в расчет загруженность системы)

Да, если обычная его реализация, то действительно долго

Это сообщение отредактировал(а) Kill_em_all - 1.12.2005, 10:51

Kill_em_all
Да я имел ввиду лишь сравнение однопоточного блокирующего connect()'а с однопоточным SYN'ом.

Ладно, хорош флеймить

Это сообщение отредактировал(а) GrayCardinal - 1.12.2005, 12:36

Цитата(dwr_budr @ 1.12.2005, 11:19)

Да я имел ввиду лишь сравнение однопоточного блокирующего connect()'а с однопоточным SYN'ом.

Понятно

А как UDP-порты просканить(в смысле если на нем висит прога, работающая по UDP)? Такое вообще возможно
У меня Outpost ругается, что меня иногда сканят и именно UDP-порты

Насколько я знаю если ты посылаешь UDP пакет на левый порт, то тебе придет ругательный ICMP ответ пакет (что ить из серии Port Unreachable). Стало быть порт закрыт. Если же ничего не пришло - либо ICMP не дошел, либо порт открыт либо еще что то. Уверен что есть еще куча примудростей. Например фаервол, который наверняка на все UDP пакеты клал и ICMP пакеты слать тебе в ответ не будет. Так что ты как будешь эту байду делать, почитай где нить более подробно и нам расскажи

Спасибо, буду искать! Но если фаервол правильно настроен, то и на TCP-пакеты
с SYN-флагом он класть будет. Во наука - сканирование
Всем спасибо за помощь, буду работать над этой темой

Это сообщение отредактировал(а) Kill_em_all - 3.12.2005, 11:44

dwr_budr

Цитата

http://forum.vingrad.ru/index.php?showtopic=73430

Там патчик для линухи от любителей посканить.

Это сообщение отредактировал(а) GrayCardinal - 10.12.2005, 14:55