Re: idea for scanning options

[nnposter () users sourceforge net]

David Fifield wrote:
> On Mon, Feb 23, 2015 at 04:52:48PM -0600, Daniel Miller wrote:
> > On Fri, Jan 9, 2015 at 11:05 PM, Mike . <[1]dmciscobgp () hotmail com> wrote:
> > > so follow along here because maybe this wont make sense, not sure. would
> > > someone ever think about making a change in our scanning (tcp/udp) to
> > > ALWAYS have the source port match destination? i read that some protocols
> > > will only talk this way. 2 i know are IPSEC and RIP (500/520). i do believe
> > > there are others but i do not recall them right now. so as you would be
> > > scanning, by default, it would just use the same source as dest on auto. is
> > > this feasible and do we even care? maybe we could do certain ports this
> > > way? or do you want the user to constantly specify the src port option?
> >
> > This could be feasible, but would require a good deal of work to implement. I
> > thought at first that it would not be possible, since we use the source port to
> > encode information about how many retries had been sent since the one that
> > provoked the response. This helps with timing, since it lets us know when there
> > is a very high-latency link where replies to earlier probes arrive after we
> > have already sent retransmissions. This is already a consequence of using the
> > -g option to set the source port, though.
>
> It should be possible because of -g, but I agree it doesn't seem worth
> the effort. It would be weird to probe port 80 from source port 80
> always, for example.

Moreover, NIDS tend to have signatures for connections originating from
"system" ports unexpectedly so the scanning would get much noisier.


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