Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Mar 2018 17:11:56 -0700
From:      "Ronald F. Guilmette" <rfg@tristatelogic.com>
To:        FreeBSD Net <freebsd-net@freebsd.org>
Subject:   Re: Same host or different? How can you tell "over the wire"?
Message-ID:  <5843.1521677516@segfault.tristatelogic.com>
In-Reply-To: <201803212204.w2LM4G8h023320@pdx.rh.CN85.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help

In message <201803212204.w2LM4G8h023320@pdx.rh.CN85.dnsmgr.net>, 
"Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> wrote:

>One thing you could look at is the OS finger printing of nmap,
>that could look for possible things to diffentiate the hosts.

Yea, that idea occurred to me.  But this solution has the same problem
that I just mentioned in another one of my replies in this thread:
Even if nmap says that two IP addresses have the exact same OS
signature, that is far from enough to assert that they are both
under the control of the exact same Bad Actor.

You certainly wouldn't want to send someone to prison, or even to
after-school detention, based on such limited circumstantial evidence.

>Depending on just what the host is there could be other tale
>tale signs picked up from "forensic" type of data captured
>with tcpdump while playing known packet sequences against
>each host at identical time.

Such as?

I'm all ears.

>What you ask I believe could be done, but it non trivial and
>would require a very good understanding of both forensics
>and the differing ways that TCP/IP is implemented.

I like to think that I am a quick learner.  Please proceed with the
lesson.

>One simple thing is a record route of a packet, it might show
>that the hosts are clearly at differing paths.

Again, not adequate, I think.  Not for my purposes.

The addresses A and A' might very well be within the same /24, and the
routing might thus be identical.  Does that prove that both are under
the control of the same single guy?  I would say not.

>If the hosts are very different a ssh connect could
>lead to an answer as it may give a differing answer string:
>...
>SSH-2.0-OpenSSH_7.5 FreeBSD-20170804
>...
>SSH-2.0-OpenSSH_7.2 FreeBSD-20161230

Believe me, if the problem were as easy to solve as in this example,
I wouldn't even be here asking the questions I'm asking.

The question is:  What can be reliably deduced when we see this?

    Address A:   SSH-2.0-OpenSSH_7.5
    Address A':  SSH-2.0-OpenSSH_7.5

i.e. the kind of identical outputs that I posited in my original statement
of the problem.

>It would also be possible to implemented controlled DOS techniques
>to cause "measureable" load on one IP, and then see if the other
>IP has a similiar measureable load factor.

This also occured to me.  Ignoring for the moment the various... and
I hope obvious... ethical and legal questions, it isn't even clear to
me how this might be made to work, in practice.

I did make it a point to look over some online simple-minded tutorials
relating to SYN cookies just the other day... not long before starting
this thread.  I am guessing that the use of those is now quite widespread,
and it seemed to me that these (SYN cookies) would render any attempt at
(for lack of a better term) "limit probing" non-useful, at least with
respect to TCP.  But maybe I'm wrong about that.

In any case, the ideal solution to my original problem statement would
quite certainly -not- involve anything as obtrusive (or as potentially
illegal and/or unethical) as pushing any host hard enough to find its
capacity limits.  Rather, I am still vaguely hoping that there may be
something burried deep down in the IP protocol or perhaps even lower
(MAC addresses?) that will provide an elegant and minimally impactful
solution.  Alternatively, if it turns out that there is something....
anmything... that is host-specific and that can be teased out from
some commonly used application layer protocol (e.g. an SSH server's
public key) then that will probably do quite nicely also.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5843.1521677516>