Re: Pull Request: Host Discovery: Ignore TCP RST #1616

--===============3264963312116620191==
Content-Type: multipart/alternative; boundary="000000000000fd8624058afd107c"

--000000000000fd8624058afd107c
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 3, 2019 at 8:24 AM Tom Sellers <[email protected]> wrote:

> All,
>    Since not everyone checks GitHub PRs I'm CCing this PR to the list.


Hi Tom.  Thanks for the patch!  My only concern is whether TCP host
discovery probes still provide much value if you are ignoring the RST
responses.  By default we use an ACK for TCP host discovery and that almost
always relies on RST packets to find up hosts.  Maybe there are some corner
cases like certain ICMP responses straight from the host that we might
still use to consider it up, but I think that's pretty rare.  Of course you
could also choose SYN host discovery (like in the scanme example you gave)
and if the discovery port is actually open you would get a SYN|ACK.  But
still, a RST is still the most common way that SYN host discovery finds
available hosts.

Since I imagine you folks wrote this for a specific use case, maybe you can
check whether you use case can be met roughly as well by just skipping TCP
host discovery for these type of scans and just using ICMP and/or UDP
probes?  That way you aren't sending time sending probes and then almost
always ignoring the responses.  Or maybe, given the behavior of the network
you are scanning, you still do want to send the probes?  In this case are
you sending SYN probes or other TCP probes, and what non-RST responses are
you hoping to catch?

If we do put in this option, it will have to be documented in the man page
and we should probably note there that omitting the TCP discovery probes is
often a better approach than ignoring most of the responses.

Thanks!
-Fyodor

--000000000000fd8624058afd107c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 3, 2019 at 8:24 AM Tom Se=
llers &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">All,<br>
=C2=A0 =C2=A0Since not everyone checks GitHub PRs I&#39;m CCing this PR to =
the list. </blockquote><div><br></div><div>Hi Tom.=C2=A0 Thanks for the pat=
ch!=C2=A0 My only concern is whether TCP host discovery probes still provid=
e much value if you are ignoring the RST responses.=C2=A0 By default we use=
 an ACK for TCP host discovery and that almost always relies on RST packets=
 to find up hosts.=C2=A0 Maybe there are some corner cases like certain ICM=
P responses straight from the host that we might still use to consider it u=
p, but I think that&#39;s pretty rare.=C2=A0 Of course you could also choos=
e SYN host discovery (like in the scanme example you gave) and if the disco=
very port is actually open you would get a SYN|ACK.=C2=A0 But still, a RST =
is still the most common way that SYN host discovery finds available hosts.=
</div><div><br></div><div>Since I imagine you folks wrote this for a specif=
ic use case, maybe you can check whether you use case can be met roughly as=
 well by just skipping TCP host discovery for these type of scans and just =
using ICMP and/or UDP probes?=C2=A0 That way you aren&#39;t sending time se=
nding probes and then almost always ignoring the responses.=C2=A0 Or maybe,=
 given the behavior of the network you are scanning, you still do want to s=
end the probes?=C2=A0 In this case are you sending SYN probes or other TCP =
probes, and what non-RST responses are you hoping to catch?</div><div><br><=
/div><div>If we do put in this option, it will have to be documented in the=
 man page and we should probably note there that omitting the TCP discovery=
 probes is often a better approach than ignoring most of the responses.</di=
v><div><br></div><div>Thanks!</div><div>-Fyodor</div><div><br></div></div><=
/div>

--000000000000fd8624058afd107c--

--===============3264963312116620191==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/
--===============3264963312116620191==--