Re: [tor-talk] On verifying security of Tor Routers idea

[Lee <ler762@xxxxxxxxx>]

On 12/21/11, Fabio Pietrosanti (naif) <lists@xxxxxxxxxxxxxxx> wrote:

A lot more than I'm willing to critique.  My suggestions are

Add a PHASE-0.5: Email out requests for permission to scan &
permission to publish the scan results to all tor node contact
addresses

PHASE-1: b) Portscan all Tor Router>> that we have received permission
to scan<<, save it via XML

PHASE-2: f) Publish the Statistics result Summary>> for the nodes that
we have received permission to publish stats<<

PHASE-4: remove all nodes from the concensus that do not meet the new
Tor security standards


This isn't that far from a proposal for a system whose results could
be trusted.  Just drop the ethically-challenged hacker mindset & ask
for permission to scan as well as permission to publish.

Lee


> I sketched down an idea of a possible process and phases to setup a
> system to monitor the security of the Tor Routers by using Nmap
> portscanning facility with application fingerprinting, by not using an
> invasive Nessus testing.
>
> PHASE-0: Define a best practice
> PHASE-1: Handle periodic scanning+alerting
> PHASE-2: Public aggregated Security statistics
> PHASE-3: Add CVE vulnerability checking
> PHASE-4: Full Public Disclosure
> PHASE-5: Introduce a Tor Security Rating
>
>
> Probably with 0.1/1 day python coding it can be done with a stateless
> system (no no change management monitoring, etc).
>
> A dedicated server with a reasonable hostname
> (tor-portscanner.domain.tld) and with a web page explaining the project
> would be required.
> Possibly something with a customized whois to prevent annoying reports
> from people that automatically send abuse-complaint (It's fun to see
> that there are Tor Servers that if are portscanned automatically send an
> abuse complain!).
>
> PHASE-0: Define a best practice
>
> Define a best practice from system and network security point of view.
>
> Something like:
> - Don't internet expose services that are not strictly required to keep
> the Tor Router functionalities (for example Tor + SSH)
> - Don't internet expose outdated/vulnerable software
> - Don't run outdated Tor version
>
>
> PHASE-1: Handle periodic scanning+alerting
>
> a) Extract list of all Tor Router + Contact Info
>
> b) Portscan all Tor Router, save it via XML
>
> c) Cleanup the XML scan from the Tor Used port (for the specific Tor Router)
>
> d) Send an email with portscan results to the Contact info informing him
> about the current status of Non-Tor specific opened port
>
> PHASE-2: Public Statistics
>
> e) Create statistics
>   - Count how many Routers have X amount of ports opened
>   - Show (sorting by "amount of open port) the list of Tor Routers
>   - Count for each port, how many Tor Routers have it opened
>   - Show for each port, the port statistics
>
> f) Publish the Statistics result Summary
>
> PHASE-3: Add CVE vulnerability checking
>
> g) Use CVE scanning to match Vulnerability Level using as input data
>    - "Nmap Application Fingerprinting"
>    - "Tor Version"
>
>   - Add data to the email sent to Tor Router Contacts the CVE
> vulnerability match
>   - Publish statistics for vulnerabilities present on the Tor Network
> based on CVE statistics
>
> PHASE-4: Full Public Disclosure
>
> When the network reached a good level of Network security  with almost
> no or few security vulnerabilities, it would seems reasonable to me to
> do full-public disclosure of that process and data.
>
> I mean, those kind of data can be collected by anyone with 2 command
> line, so they are not secret and it's not difficult to retrieve it.
>
> So it's reasonable that, after a first assessment period, they got
> published.
>
> So in that phase also the "raw data" will be provided.
>
> The name of Tor Nodes, hostname, IP address associated with result of:
> - Portscan
> - Application Fingerprinting
> - Matching with the CVE database
> will be fully internet exposed dynamically, with grid where a person
> would be able to see statistics of various type:
>
> - All outdated Tor Servers
> - All Tor servers running outdated software
> - All Tor Servers running un-needed services (like a SQL Server)
> - TOP opened ports servers
>
>
> PHASE-5: Introduce a Tor Security Rating
>
> Let's define a "Security rating" to provide a "number" associated with
> each Tor Router.
> That number could represent the "compliance" respect to a Best Practice.
>
> All nodes would get assigned a Security Rating and that security rating
> may be then used directly by Tor Client, for example to use only Tor
> Routers that are known to respect the Best Practice.
>
>
>
> From here a continuous ongoing process will always guarantee and show in
> a transparent way which servers are following a best practice.
>
>
> In the end by implementing a process like that, in the medium term the
> Tor Network will be much more secure because there will be a public
> incentive in keeping a Tor Router secure and following a best practice.
> _______________________________________________
> tor-talk mailing list
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk