Hi Roger, > There is a fine policy question here, which is "ok so what now? Do we leave > them in place or bump them out of the network?"
This is just my experience, but reaching single node operators has become notoriously difficult - I frequently use metrics to find out-of-date / potentially vulnerable nodes and e-mail the associated e-mail address. On average 10% actually respond, but most don't care or simply forgot about their exclusively for Tor-purposes made e-mail address. I usually wait 48 hours, and if they didn't respond by then, I try again and wait another 24 hours. Most people actively monitoring their inbox would have either replied within 2 days, or after the second e-mail. If nothing happened after 2 e-mails and 3 work days, I usually give up. The fact that cups even binds to public interfaces and doesn't come by default with a whitelist for LAN networks is mind-boggling. I don't have any advice regarding flagging these nodes to be rejected by clients, since I don't know the volume of traffic they transport on a daily basis. Regarding scanning (exit) nodes for malicious behavior or vulnerabilities, I am all for it (as frequent as resources allow, but as fine-grained and accurate as possible at the same time) - I don't know the predicted percentage of LEO-ran nodes right now, but any percentage is too high. however, I know that it can be extremely hard to distinguish. I think nusenu had some great articles on the problem, and also some effective tools & algorithms to detect malicious nodes. Just my 2 cents.. All the best, George Hartley On Sunday, September 29th, 2024 at 6:15 AM, Roger Dingledine a...@torproject.org wrote: > On Fri, Sep 27, 2024 at 09:41:29AM -0400, George via tor-relays wrote: > > > There are some very significant recent CVEs out for CUPS, the unix > > printing system. > > > > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=cups > > [...] > > Needless to say, a CUPS server listening on 631/tcp or 631/udp while > > providing Tor access is a bad idea. > > George and I took the opportunity to scan relays and bridges to see if > they have this vulnerable cups-browsed service running. We found 14 relay > IP addresses that did, and 4 bridge IP addresses. This is a pretty good > rate overall! > > (I had been expecting to find more bridges, because they're more likely > to be at home and people might be running them from their stock Ubuntu > desktop install or the like. But we found very few, and maybe that is > because at many homes everything is NATed/firewalled by default.) > > 12 of the 18 had proper contactinfo and I emailed them. One bounced, > one replied and fixed it, and the others haven't replied yet. > > There is a fine policy question here, which is "ok so what now? Do we > leave them in place or bump them out of the network?" > > I figure I'll wait a week or so and scan these 18 again. But I fear that > the package "fix" will just correct a buffer overflow or something and it > will leave the "they listen to the whole internet and add any printers > that the internet sends them" behavior intact (because one is a bug, > the other is a feature), so my scan won't actually be able to tell if > they updated. Fortunately, which next step we choose doesn't matter much > here, because the numbers we're talking about are so small. > > There is a larger conversation we could have, around whether we should > make vulnerability scanning of relays a more common or automated or scaled > thing. I like the idea in theory but in practice I don't think it should > be a high priority compared to our other network health priorities. > > I'm tracking details and next steps about the cups issue on the gitlab > ticket, > https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/83 > > --Roger > > _______________________________________________ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
publickey - hartley_george@proton.me - 0xAEE8E00F.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
