Skip to main content

Timeline for nmap SYN scan taking forever

Current License: CC BY-SA 3.0

8 events
when toggle format what by license comment
Sep 20, 2021 at 0:06 comment added m4110c @multithr3at3d Could be, and of course, you could setup the scanner to mimic any desired behavior... However I don't know of any protocols that connect and immediately disconnect after that.
Sep 18, 2021 at 17:44 comment added multithr3at3d @m4110c perhaps, but I wonder if this would cause lots of false positives. I could maybe see legitimate cases where a client connects, but decides to close after receiving a message initially sent by the server. Depending on the protocol in question, of course. For a protocol like HTTP, this would not be normal.
Sep 18, 2021 at 12:34 comment added m4110c @multithr3at3d Wouldn't it be extremely easy for an IDS to just monitor what happens after the initial connect. I mean, even if you'd scan just a single port, you will not send any legitimate data afterwards. So if I were an IDS I'd reason: "Ok, we have a connect with no data following. Must be a scan."
Sep 17, 2021 at 1:44 comment added multithr3at3d @m4110c a single SYN scan could be flagged by an IDS, since it doesn't really follow the TCP protocol (at least in a normally expected way). Per contrast, a TCP connect scan can be detected, but the IDS/IPS has to determine whether they are legitimate connection attempts vs. a scan, and would have to wait for potentially several ports to be scanned to know.
Sep 16, 2021 at 11:21 comment added m4110c This supposes, that a TCP connect scan will not be detected in contrast to a syn scan, right? Why would that be the case?
Feb 2, 2016 at 16:33 vote accept Sidahmed
Jan 23, 2016 at 19:56 comment added Sidahmed thanks for the answer man, but is it really normal that SYN scan takes more than 100 times more time than TCP Connect scan ??
Jan 23, 2016 at 18:12 history answered multithr3at3d CC BY-SA 3.0