[CF-Devel] metaserver tracking of clients by OS?

Tue Sep 14 17:59:24 CDT 2004

Port scans are reliably enforced on most large IRC networks without problem.
Personal firewalls, for the most part, do not significantly hinder TCP OS
fingerprinting...

More to the point, it does not involve involuntary disclosure of
information, as does client sending uname -a or similar.

-archaios
----- Original Message ----- 
From: "Mark Wedel" <

     mwedel at sonic.net

     >
To: <

     crossfire-devel at lists.real-time.com

     >
Sent: Monday, September 13, 2004 5:08 PM
Subject: Re: [CF-Devel] metaserver tracking of clients by OS?

>

      Bob Tanner wrote:

     >

      > On Saturday 11 September 2004 02:41 am, David McIlwraith wrote:

     >

      >

     >

      >>Suggest nmap -O remote IP, and parse its output...

     >

      >>

     >

      >

     >

      >

     >

      > Are you suggestion I port scan every IP address that has connected to

     >

      > metalforge?

     >

      >

     >

      > I have a feeling several people would not appreciate that.

     >

     >

        And it probably would be only of limited value anyways (given that many

     people
>

      run personal firewalls/routers).

     >

     >

        That said, while the metaserver can't track clients by OS, the server

     could -
>

      currently, the client doesn't send that much info to the server, but it

     could
>

      certainly be modified to include OS information or the like.

     >

     >

        Just a note, this is a list of connection types of metalforge for the

     past few
>

      months:

     >

      CS: connection from client of type < >

     >

      CS: connection from client of type < DX_CLIENT 125>

     >

      CS: connection from client of type < GTK Unix Client >

     >

      CS: connection from client of type < GTK Unix Client 1.2.0>

     >

      CS: connection from client of type < GTK Unix Client 1.4.0>

     >

      CS: connection from client of type < GTK Unix Client 1.5.0>

     >

      CS: connection from client of type < GTK Unix Client 1.6.0>

     >

      CS: connection from client of type < GTK Unix Client 1.6.1>

     >

      CS: connection from client of type < GTK Unix Client 1.7.0>

     >

      CS: connection from client of type < GTK Unix Client Post-1.6.0-CVS>

     >

      CS: connection from client of type < GTK Win32 Client 1.5.0>

     >

      CS: connection from client of type < GTK Win32 Client 1.6.0>

     >

      CS: connection from client of type < GTK Win32 Client 1.6.1>

     >

      CS: connection from client of type < GTK Win32 Client 1.7.0>

     >

      CS: connection from client of type < Illuminati>

     >

      CS: connection from client of type < Perl Bot>

     >

      CS: connection from client of type < SDL Client 0.02 Alpha>

     >

      CS: connection from client of type < SDL Client 0.03 Alpha (Kiev)>

     >

      CS: connection from client of type < X11 C Client>

     >

      CS: connection from client of type < X11 Unix Client 1.2.0>

     >

      CS: connection from client of type < X11 Unix Client 1.5.0>

     >

      CS: connection from client of type < X11 Unix Client 1.6.0>

     >

      CS: connection from client of type < X11 Unix Client 1.6.1>

     >

      CS: connection from client of type < X11 Unix Client 1.7.0>

     >

      CS: connection from client of type < X11 Unix Client Post-1.6.0-CVS>

     >

     >

        There are some pretty old clients connecting there (1.2, and I think the

     ones
>

      that don't include the version predate 1.2 even).  Note sure what

     Illuminati is.
>

        Of course, since the client is open sourced, one could change the string

     to be
>

      whatever they want.

     >

     >

        The problem with adding system type/os type is the fact that it would

     only
>

      take effect for new clients.  So that may not really help to answer the

     question
>

      on whether people are running on platform XYZ.

     >

     >

        OTOH, to me, disabling those isn't any big deal - if users complain,

     well,
>

      then we know to add them back in or otherwise figure something out.

     >

     >

     >

      _______________________________________________

     >

      crossfire-devel mailing list

     >

      crossfire-devel at lists.real-time.com

     >

      https://mailman.real-time.com/mailman/listinfo/crossfire-devel

     >

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel