допустим мне нужно найти в сети HTTP сервер. насколько эффективно сканировать сеть обычным connect на 80 порт? или есть более разумные способы, скажем сначала просканировать сеть ICMP запросами - получить набор IP адресов, а уже потом на каждый из этих IP коннектиться на 80 порт.
сам понимаешь что пинг может резаться (конечно в нормальных сетях такое редкость, а вот в студенческих общагах обычное дело, хотя в таких сетях и веб серверов почти нет, всё на ftp или smb), так что imho многопоточный коннек на 80-й оптимальный (единственный) вариант
ок. пасиб. тогда ещё вопрос: недавно тема была - изменение времени ожидания соединения ( setsockopt() ). если уменьшить время ожидания, то увеличится скорость сканирования. мне необходимо сканировать локалку - там время отклика, как правило, не превышает 15~30 мс; вот и установить его порядка 50мс.... или всё-таки не стоит...
дык что б быстрее было, ато можно ж ждать замучаться. А почему собсно многопоточность в топку? незнаю, может и стоит уменьшить если юзать один поток
блин обьясните же почему в топке оказалась многопоточность и connect на 80й? Имхо без многопоточности никак если нету особого желания минут 10 ждать пока сканер отработает, а чем можно заменить connect?
Ну, насколько я понимаю, ICMP пакет идёт намного быстрее, нежели устанавливается TCP соединение.. вообще дальнейшая работа с протоколом ведётся на вининет, так что connect тут по сути дела и не нужен - просто нужна проверка - открыт ли порт, точнее найти все машины в локалке на которых этот порт открыт. Вот я и подумал, что сканирование можно проводить в 2 этапа: сначала находим работающие машины, затем фильтруем их и оставляем только те, на которых открыт нужный порт. Что касается многопоточности... х.з. многие её вообще отвергают.. лучше, конечно, создать асинхронные сокеты...
найти работающие машины можно однако чтоб узнать открыт ли там порт все равно ведь прийдётся сделать туда connect по другому вроде бы как и никак...
Повторюсь еще раз. Nmap в руки. По мимо connect есть еще "море" способов сканирования. Код (Text): Nmap 3.81 Usage: nmap [Scan Type(s)] [Options] <host or net list> Some Common Scan Types ('*' options require root privileges) * -sS TCP SYN stealth port scan (default if privileged (root)) * -sF,-sX,-sN Stealth FIN, Xmas, or Null scan (experts only) -sT TCP connect() port scan (default for unprivileged users) * -sU UDP port scan Кроме этого есть еще несколько экзотических способов сканирования.
Сканер тупо перебирает все адреса подсетки. Допустим он пытается просканировать несуществующий хост. Если мы сканируем прямосоединенную сеть, что connect, что отсылка ICMP займут ровно одинаковое время - ARP протокол не сможет разрешить ip адрес. Время будет потрачено именно на это. Если сеть не прямосоединенная, то тоже самое случиться на шлюзе. Посему говорить о том, что ICMP намного быстрее - не приходится. Кроме того, ICMP запрос будет с большей вероятностью отфильтрован на промежуточных маршрутизаторах. Я намерено не пишут о "продвинутых" методиках - типа SYN, FIN сканеров - это развитие, так сказать, базового метода, основанного на обычных коннектах. Кроме того, речь не идет о сканировании машин, находящихся за фаерволлами - тут может потребоваться целый арсенал методов .
я и стараюсь уйти от громоздких методов. Что касается сканирования локалки через ICMP протокол.. помойму иногда на машинах стоит запрет на ICMP ответы.. Ещё: широковещательные ICMP запросы - я с ними никогда не работал, так что сильно не ругайтесь. Почему нельзя послать в локалку такой пакет и проверить все адреса, с которых придут ответы?
Можно. Все линукс машины отзовутся ( если конечно не запрещено фаерволом ), Windows - будут молчать. Винды с ICMP броадкастами гордо не разговаривают. Кроме того, броадкасты возможны только в прямосоединенной сети - в соседний сегмент их не пустит шлюз.
connect'ом можно эффективно сканировать. Делать нужно многопоточно учитывая лимит на количество сокетов для одного процесса (у меня на хп сп2 было 10). Сокеты должны быть неблокируемые, после вызова connect для таймаута вызывать select и рубать их если коннект не прошел, иначе подключения на блокируемых сокетах будут довольно долго находится в состоянии SYN_SENT, и только потом отвалятся - это довольно ощутимо скажется на общем времени скана.
только асинхронный коннект скан. многопоточность отъест ресурса и вряд-ли будет быстрее. icmp в топку - после получения icmp_echo_reply тебе один фиг придётся делать коннект, чтобы проверить 80тый порт.
