On 12/21/11, Fabio Pietrosanti (naif) <[email protected]> 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 > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
