November 2020 - tor-relays - lists.torproject.org

I bumped out some more bad relays
by Roger Dingledine 10 Dec '21

10 Dec '21

Hi folks, I spent some time this week refining a new exit scanner, and today we pushed some new reject rules to kick out some relays that we confirmed were running mitmproxy to do more sslstrips. For past context, see these urls: https://blog.torproject.org/bad-exit-relays-may-june-2020 https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html https://lists.torproject.org/pipermail/tor-talk/2014-July/034219.html Expect some upcoming next steps that aim to change the fundamental arms race, including experiments to use https by default in Tor Browser, either via HTTPS Everywhere's "Encrypt All Sites Eligible" option (you can turn that on right now) or via Firefox's upcoming built-in version of the idea: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19850 For completeness, I'm including below the set of fingerprints that we bumped out. Note that we didn't confirm misbehavior from all of them -- some of them we're bumping out because they seemed sufficiently similar to the confirmed ones. If any of these are your relays, please speak up! Thanks, --Roger Group #1: COMID (coronamitmdisease2019) at OVH 019839E66C7229039367BEB4E83B27D08A9C2B37 110F26C0BFB2122BBB856EADC9A2D497989DE949 1B473D4B5C1D7C594E88B3044823D04E2BC51DBA 28EA24439668FBE905C801F8170C192E119C9FBD 378C5C8381700EC68EFDC427148CDE18DD94A014 48325E9146758F8636473D6D25FD4D7734E189CB 52DDF76A32CC3E0BFBAD72E511A0354343A224B3 7A8089D801EC09B20B1091CB031C79B7E0371818 7BD7DB37884F3DADC61E755FA9F03F499BC3C552 840C79C994150D6F6A48B5F8E8658AB74D36B052 852FB4885C5F9DEDE66BB9E5515A81EAE6E43B6B 8FAB1ADF9BE2D0E821AF92B8215F692CD715FD73 A2BA8791AA2A27DCB5B0C5B51E8CCF2337A5C1E2 BD32854443E891DBB685E43854BB382DEF081E94 C271F036CDFE8A90881B60712BF6ACF742259764 CA2F7497106CB8B9AAF0E1A7CF9866EAC9DB43B5 D26C58809FBC2C0D0251FB2991470A6AAB3EDC5B DE50C4066BE7200F5D6AD0FC88452667451D39A9 F2D5E3A3E8B11CA72FF340C450A46F4C67AD8D1E Group #2: info(a)cypherpunklabs.com at OVH 023455597DAB689EE84FB3A7BC7FC5F9A3E27FD6 044E647F34EDA4AC975EDAD628C4E9BCFFF1FB08 04699AF0CB2B5A7F5CF943D31011F50F601BE8C7 05601B110B888BF3A12E10E8BF3C0B02166BF3F1 075FDD85EF4B783BCC9040580168F1FC5576B101 09930800210FF35CE84F2DEEDB4F9B67812B9717 0B7B08C50E419004F77447A72FFD578061F58311 0BAE1E20ACCB1F454A3A473185D83743E140B9D5 0BB27C3A307B35B5B2D2E8774D69DF7FA4B97867 0BE6EEB76C5641BF5D2E63C49C28CD50D2A40C15 0BF30C2AC9DBEF9C79B1119808F2FCC3FD81EE0A 0D58067912EA84D955565C82A4C00A47CDEF11DC 0DD55CF27BBA1F51131A46BC0A0EED68A177D1BB 1766E98ECC8A457FDBCBA7322C93F51FE1F896E7 186FF078A2EE09E8208ACBF4DDB61FFF96AD64B0 1B1351D85E8328BE21539EA9C0C0317E3A1CE380 1BD9EEB6725555246E8ADFFA5FA6B1D82F43447D 1C11D59B0144E9B33BB932A031BA8A3A5B81C65E 1D0971FA9B98AE2807D6A44AE6EB7EB120AB5675 1D515E91312D5F79895D607D6C27392DD5F6A84E 1EC0CCAFA8ABD5470B062AF470EAC97DD069C655 1F00A270AFDA1172DEDEC138AFEE977CFFB0FAD1 1FD39D081A3AA8E3D6F0962F8281A448D536C879 2369F6855A7CF31E3174CE26678FBBAD6A31D883 23BCFD8AB533AAE05639D1D79A445DEE76F8E57A 2541C0EB6F66C1344B3F14AB65EE7D6882EEF15F 29EC42BC7A3E7ED811578D5F656EC76D7A7AA2A5 2DE12251A7AF25B2CDFA9DE0F1B4022685ABAF3B 325499E7D6927D51229019F2EE031F26EBE095BB 386425D28458D4DB41F74F256AFF99ADB7E25271 38C36322890194015837A1085907DFA6AE3A9B00 3A6164437EF523E4907E7D97CAB135EFC39621F6 3BB398CA2D1F1E83AFC46641ABF8FECC989B8F19 3C5491293747761AFE9AF014FDA4B92960304D21 3CAA25A190B2F030DE86D0E99329E4D399472FB4 3CE91268F607E373482D1BCD33018CF1C77FAFA6 3DF6717E1C62D9ACF65CD5B3C609FBB271D9586D 3EE2A784ADB2F56E631F281F2688104A656E19C2 41280DE9ABE5BF10F7F5DCB13A28C07082064147 41E9201B42807012BCAFA6B94BCF9AD00CD787EA 442058BAE48FDFA68A3992988CBA6E2035FA8782 446FA7DE8A5DC2F2B0EBB9083753D127BB217F60 466F6F3B37435A6285C1F73F49EC58FA9D3A5260 47B22D6B46447B533E962966B9559E249B6F915C 4B777C07DFB28938D7D9B84737275F2412B5CA2A 4C52890A00964648E3AED7EB7CB178BA082610E6 4C6E75E65818844B7D3F3A8A9666525680006EAF 50A4A3A09AC7BC09F578670618A9BB864772EE03 554E9EE1586220B016B7C43490E7398F57C254D5 5A8A80399011B703FDB40E11226A389162DE0DD1 5BA611940BC239597312636D257F615F4F4D7BEB 5E6CB5FC020088CFC99342784A4109E468D7C94A 60D6F3FEE07527E749BD6BB3E401E5EB389EA45C 62CC081F58E5415DDD49A20D80A0E9A8A2E35CF3 63E4BD985E436877C471A743F1625F10FA114458 678FDB3BA0EEAA2572329A0BB0FF50E449D714ED 67FBB854B6DBD2DCBA5747FD761BF36096EFC0C0 6B6B3650F2FF83BD767AD84838600C62F937558B 6DA708660BA6F0BE1B67434951F0D0FE6AE72728 753C8EEDB1C2A9E1DBBF4DF75A2F549FD1A7F0FC 8002F46087D145E1CC5F4F11725494059E7A823D 80DF1465F2F27AA933DDB3A8F8A2AE06D3D859DA 823C31DD41F31ECDB44DB17198EAC2EDB7A295E8 85BFDBFCF9E711CF0F1A22C115368724D7C101F7 85D895B55F1A021663D441587F4FD822082E73C9 8668B39793EBDADD148AE8BB256B1E2E6ACD78D5 87B449E227ACB5C3FEB580942242183993866138 8D112569E620CB316F1FDC08BCFD93FF54F22ED9 8D599159A555665F199DD0F9E81277417C8D3973 94729C093EBFFC6102C47EE1EB40A8827AEF28E8 968CF9A51740B682ABE4DB11829488281B66DBD8 99F01989477E1F553BE789E25FB63CC2A2276E33 9A46602C82BD2C174F1C115A1D6E012DD0DFB57F 9C2EF7092D80859AC3DD4A39DF50B725D2BC3D5D 9CA1FCF374E5CE8F652DB08B16BB874EA839C0BF A3317BF385CFF595CC27997BB5A6C2FB35846D47 A6DBE4FFB33677E56BBBD0911AA489927650ADCA A7FA78D175541179556D66C8C78D69D238274F7A A81B621D6401BBEEC8E2C84228141BAFA711D0D9 A8D70BB95B76B3B5E6F6B4E30C2EFB11A21E9D1F A8E6126DA7D6DE9A719162CE8980F8755B612F21 AED640FB85D0A5C43C756FBEE19D1075DAF8E686 B34E09B1C68F46483A1A90551ACC78D87C80C08A B6F6B44DF12B2F1B74B666AA48F2BA0E5CFDF169 BA38FDB6FE97442388C35FE83F371BB1C6C4324B BA405E953DBE33BA2388F6B5954EDFBCE4CD1196 BC70877D0CBDFA77E6B4B88DDC23D03F8299CC02 BD9E37F7FD8773AD0C07B22394F179288DC5E2CC BEE5A27A9DD05BD7D9B6E046AEDEF43D2A4B85CE C31A5F636926B69C72F992F005D0BDF48040B283 C50ED548D22C1908E58AA194AD3DC966FD267E06 C6F1E2ECA92A5DE6710F1317DB040EF2CFFC5C92 CDAA1A9F705EBE23E9FB63B3EFE6699205E2F8C6 D018720BE031BA9CC0DF4C0E21ADBC649C325C62 D2816DE9B3040231DE6A431583C26FE65B5C929D D57751F73AE9DBFEAFAC282473615E5F6D269614 D7204D395ED3E4B6F6D81C38D8D6A9241F58250F D74C47EA991FAE041C2CBB233493C6780B197A14 D888307FB9A44E75FEDF0DD2DE3AB9659E6DC6F9 DC74048330C6037ADC505E0AF63E2A9F765F6B57 DCB6273B2D2AD09AAC021141136CD461994D1533 DFE448D8C5D81AE687289A225B64F704A7FAC877 E5A3F4D29B0E3AC5DD93D9921FE203702F558BD0 E781B862FEBE3C40029A0350BB0ABF4E184086DA E8F32BBFEAD7EDC6A40732EAEB15CF5C6DEFF225 F0CD6DD3766EFB6CB409EB148B6B22FF0B765533 F6CDD5AAF675F44B88BB326EC0738BD7277CBC12 F8E6613A7AA382960E00FC70A2E15A7B2F3F3FA0 F9DF89DCD30D238443245B5483A5E10F3D52C101 FA611C0BABB9DF7A63AC2877A5AB5A6880FBA51F FC33CA0B739EB8290180C7D22A536726B8EE90E4 FD00BDB335960AFDCA6CD565B81DEF2BA7F27E7D FE9313D50FB0E68F674812BF7CED0D8F2C2B65E6 FFF5DF7E9EF2A78210BE8E17E396CFC79797AC92 Group #3: Cypherpunklabs(a)protonmail.com at OVH 0D97E4B39B1986B688E90BE1FD996E492F2552DB 0E0D2A2E71A61B9D209DB4CE5E6DBEB98473E4EB 175D1B74B0271F5997C27E020AA167A013FFB7C9 215A723CB44D8ACB001D12C7832FC742921B4F64 241F67E50CA7D5E522F94E28B5AB5ABE4F166616 2723A5FFD3B6ED842EB44C380D3AB4D26DEF60AA 34BA457C5120D5E7DA9513C7B98733C57503E3E6 3A992EE90A372FF4ED0DB1E26D9662E967C84A92 3DAEC5687EAB19CC9FBE98303780137E143236AB 4169E219D6FFCF419A5F5DA6A66E0DC5782F8F8B 42215683AE0D359B6BADF2674D09BEA348BE388A 438587D73152254E935FC1D387003DFA18166EC5 56B310D18861A5F2A57D73269B6C11EDFA4EED1A 63584BC1EF29E794A63C264136D7825C33F0889D 78E40CFC92AA9265BB50494B75BE8E7F94659E8E 8049F8C058587A66246E8A93A56957CE29165F72 84D4A8CCE76EEAC3FC45ED7A78A05F7DCD68CE72 A613E402885F5D248889CD6EA85DE61D022D760E B3AA9132A7D759863BFAB6CD12DA6646F2A5D1AD B4598727C0B2A1313AB9DE822EDC6ECFDCC78FC0 BE1E17C00A4BE0FF280CFE062D03F261061E2E63 BE48173BCF9F2C3448192916BEEF01EA745F7DA3 C1C568D3802481F1BC15F9CB75A4B4DF7592BE50 DC818C243B318D19D07DACFC2E7CAD327C7E0B3E DE81E82F60AFCA34FB5F94D78F590FEEBB435CDC E05546C3458B68C2B1ADC7273AE0539E6325B910 EBF91C6220CE4890E2E94D32F3B6B96991ADC807 EC1EEF4ABBAA11CE8C978E6C87182F63AD27A4F8 F5AD7DE58D0E038B48761AD995F9117DA072BA47 FABCC633B0DEEE6FABEF3FA415A2B0038B2A5A00 FC8C3644FEE491C828EF7A980F9E2CB0D12F4D0C Group #4: other OVH relays probably run by the above 029F57C3B3504B797C189C208AC57B5D141F66D3 05EEF2F6029F70734AC5F64557AA2FE37306214F 11F30B96054A494093AE43310B1BD681AF76CADD 13E07E74D492BAC41B6C83DF66CD6022C576C4CF 18D0C3D3145B3F6FE48D13030A3B62641CBD3969 199937E2431394D8FE1219535763ED45DEEC6F9B 1B7A8EB93B36BAE221B5E0B66688864F508CDEBA 2254F9FB12C036595777E3C55C7F9AEEFDB3A0A9 309A43E7861F9DDCBF9C063B7FF94C53C7784BCD 336815FFC4B20050F240827FCDD20A66454C538C 3EAD45A64281E3447EE501B3D88CA8FBB041C749 4ADCECEF8450D38FAD26154A3689CF5DD53121EA 551CF8E26FD81CD95EC75E7530A6ED5120AFA769 56731D73A7BF7600C2942ED84F2371B9BE26117C 6513031975D1B4835C5483F482152B85BBA8F2DC 7F52A31991B48A95A52EDE2CA4E161ED70124B4A 815E359B9C9CC44B9CE2D7233D40E96AF9000206 89BDEBC7DC4FB7FAA0914E18167F3E9A69E20700 8D4AA79E47B1C99116DC8E8F301BD574021B88AE 9CBF4C88F2C687DB501A374ABB960EDBAA1CD911 A249B7EE9F843694A8CCE1DF8DBE8627A1EA51CB B2DB1519E42B22BF2C204D2873A2021BEBD7249E C52426AA31F0D90A4E53320858B98547A81BC86D EFAB57D3EBABB4F922F850763E88B447A2F4CC09 Group #5: at Frantech 13BFB7E95E303AC22A005F7D4D08CA9655925B40 14F21BEDEE20BED716234E7026822DF9E69EC356 1EBE3083FCDC9658188A2C7F67B83C531E641039 1FBEAFC6CFE71F1EEC3D5F62A2D896B1F87B2F4D 258837F888FF885131F8F12BC409D69F99597E6A 2DBA4CFFFD04A3EDA74A58264B4E4F351AA0F5A2 3D07B333ED3A81C557D39DE8A4EABD9BC0D6B0C1 3DCFC8F04E088BB33228FED97662D4E87B0F195A 3DE14798CDD62F6FA29DF21F418B4DFCEB0D59F4 3EAA79A75F96F4A082DB92E5FA231452BAD3F80C 4084E7226F6A6463C32F28841EA10A7796D10254 475C893CCA9661B407865B6DBB30C021AE45F1DA 6636D34B1502FABFE0DF848043CBCC0E4C52F12E 6E4DC86BC268306583E6C5640F11F17677663EDE 70797E7080F116E302A0F2A8F901FE914A3E625F 817C637920A7D4036CF665C6EC2D9842A7E73B77 85C8DBFB5574A338CAC8603CAF330EBF93219079 8A4C65C62D82C8783A6B51379A0E033464A4DF3C A40D5345ACA7439DAEA3801C3C473731B68A6E9B A95E579F730F719941392B6282676319839627F5 AD2A2BCC14044DA38F17FF37E6416C30BA1DF80B BCE0092B89D2C804483161D6E4C8FC81C56AA2B6 CED3133934C7B50F5A66323BC37AAEDDC875460D DB739627A2E20DE302A0D25F21B8B372D4AC2963 F44CDC27499333A14D55B8E28B9240BC8B206532 Group #6: at Leaseweb 0110D7D65C572B36C4CF4DD564B0BBB0B2ABF98D 08D8EC605A5CF77B6AC3F9CF34FA2B32E6F0EB3A 0B477F70980938C5287C04A8256951DEDBB72E4B 17038EAF590FCFCD4D17BF800892D61498D922D2 1818B3DA74DCBFC796CBA1011CEF41329B500DA6 1A7C2D579CDCE10C85E42FE515EFBA48A17A7D17 1AC81B2F05A3EE1DFEA330D3FD981E2E7F450C79 28724DB378396B1CD079D75824D9ADAEABC4C469 289730865CD9615FDAE620C65C973B3D99F6BB07 29AA1984FEEFA60093F72160B5EF44CA50B4EBBD 319A356599E538FC22697F8E982D94E0611C800B 333396E790E6CFA31C594B0D5F08DECBD02F8FEA 349379251F9F22044F46B214EC793DF724341096 36A358DC10EC2195303E141FC408A0706E5DFD81 3767BCA088F4C54D688F47C57B9868C9DF7D8D64 42EECE234646FB6CA84552BE7C915867E2ACDAC1 46A97AF8E2E20178EDD4D9F931B054FC1BEDC00A 47E7F131379F8DEC0909F2F9395331F4C67A538A 4839BD15B8E8BBDA5CDF304ECD7516D104CDC7F4 48E6494B14CAA7DFB4D87E0A76CA829F37C8D1C3 590D532DF6DB0E4E55150E397F2EFC3ABF76E755 591361152F37D13DCE8FA5827D109071725416FC 59571FEE54462C0E1B540D1E155B2334B9F10498 609A3FC47277EFD1683A0FC5A5FD07E261D0833B 612BF4A52D0DE957BBE376D4ED5A4203F9B2D7B6 62074297A05126F4C9C4F30F1338FD6C69099623 6A676D859C2D12CA8B699E710DF63CACC406B08F 6C03F70B7A90BF179ABBD3E0A854C2A1AF123966 74F71248F22646392AF63D4C4170C3B3A02E48A7 777F3A4B86A4042489F21F0CE608BDB8026BFF5A 77B6C374D5E16FDFC7698A645383CA9914F379ED 7BA2E40A27A96505FD22CB3BCD12E3B189CFFCF5 7E8834745EF551B668F83489F56D24B05A1F897F 808B7A04D08C6D2DE38FBE3D25EC7BC745B8D341 85F1A5CBFDE60BC53F00D1E98165A259AB984B58 89CB9B4F63638DB8C3702E0990845B2170B914BA 8AB40AD126DAC0C5A7C04B17CD85315E0D32B14E 9C432CC79130F4B923ADCD853A1ED621798728E6 A1F0D5720A71E6608DBB488CEA25BD5F1FA6E95B A41E8E3246F5750A16566DF04B38CE82CB111879 A47CF942FED91883C7EF8A8431939010CE95B206 A60A7FED7F5BA22E4B37CF238957BEF152474DA5 A64ECD9EE939825EF430175365E83643FE190BD1 A95F8F3E558D0D5B4CD3BD935EEEA14C73094A52 AE073E38C4DFF57D1AB187AF8FD523F76A9F5CBD B38F79C0789282F69D787B2133C9F8F4D1FE95E6 B3BC12E565A58902BD4E73EAFFC6AA98C46F417B B5F6D1B3AF78C55369262DD17D11420C6862142C BA100669E3D81203339579FE2224D0A7E37422AA BD7D0FB739E204D23B1B0B74DC9D8E311A0552A3 BE220BDCF8AE4E9F7DDAD2BAF85C2B4CB1A592E1 C14DE0D48928ABE0C15837CF35D070E0A3B8F0F4 C5197F6405A6F1423978683272A648FF79833F7F C556E08E13E012ED234362C1EEBC0588AAF1F1FE C75B26E3D4675F93F15AA2518860302A43D9BAC3 C85B7E5F3D06AB55AB0465E5CF66E777B1375DE5 CCC48AC17A89195AB8552EE9B5734C40B47B1075 CCF5C7C279A21C592E5DDF67D57542DD84C7146A CE67975EF0235DB732ADA85C6BF36CFDEFA18555 D25B78BB13249FA73B1AA5641847A66BDF014A6B D35EF561445474543064CC0C531BE0F3CCD198A4 E158EAA8788B8CFFF06A4D888D0C6B28DC1F057B E4B00CD81069AF2C0841B82A582C63AA32F03B0C EA8762F2D07FD5FA29B6BE05AA567A28D1545B4F EF0682CFD3724312FD550EB9646F72EFCFBA1B1D F788B67C42309E3B3A889E4CADB75D962CBF81C5 FB71593F68213499DA493FF6A4BFE015203272C9 Group #7: other 4E6C7297F16523A236EE1A2EE23AF54ABEF15490 55D490E9E440DD4458F16ABCDD79F48396D55EA9 78F699D58F3353AB6C4CE39E3BD96CE87439753A B1896E58FDEB5627B6B8334E6ABD42767AB8B0D9

5 13

Dropped off consensus (0.4.4.5)
by Felix 23 Oct '21

23 Oct '21

Hi everybody This is early. Yesterday I upgraded Ichotolot60 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E from 4.2.7 to 4.4.5. Now I see in the consensus health: moria1 Fast Run Stab V2Dir Valid bw=566 tor26 Fast Guard Stab V2Dir Valid dizum Fast Guard Stab V2Dir Valid gabel. Fast Stab V2Dir Valid bw=1130 danne. Fast Guard Run Stab V2Dir Valid maatu. Fast Stab V2Dir Valid bw=1200 farav. Fast Guard Run Stab V2Dir Valid bw=2970 longc. Fast Stab V2Dir Valid bw=490 bastet Fast Guard Run Stab V2Dir Valid bw=3520 And _no_ Authority "owns" the relay. Old Apr 02 21:51:31.872 [notice] Tor 0.4.2.7 running on FreeBSD with Libevent 2.1.11-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.4. New Sep 18 21:00:22.384 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.1, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. (Yeah, some Lib stuff is new too, hehe) The "Guard !Run Stab" consensus looks quite interesting to me. How can it be? Other relays with that nice "Guard !Run Stab" dropped off consensus over night (or since days) and no authority "owns" them too: HORUS1 0.4.4.4-rc norisknofun 0.3.5.10 ULayerKiriakou 0.4.3.5 Stellvia 0.4.3.6 torexit42 (StaleDesc) 0.4.1.6 torpidsDEhetzner1 0.4.3.2-alpha (3 days) karen (StaleDesc) 0.4.2.7 Stephen304 0.4.2.7 (3 days) Rigel2020 (StaleDesc) 0.4.3.6 dgplug (FallbackDir, StaleDesc) 0.4.4.5 =?= May-be the operators updated and are now in the same floating position? May-be this is super normal and came to my attention by surprise? Anyways, I let everthing run for a day or so. Time can heal. -- Cheers, Felix

5 8

SSH
by Андрей Гвоздев 29 Dec '20

29 Dec '20

Hello I'm running a TOR relay, every time I SSH to my server I see a message that there were thousands of failed login attempts Do you see this message too?

10 12

Fwd: Thailand block
by BRBfGWMz 28 Nov '20

28 Nov '20

What provider do you use? How much does it cost? \---------- Forwarded message ---------- From: Dr Gerard Bulger <gerard(a)bulger.co.uk> Date: On Tue, Nov 24, 2020 at 08:29 AM Subject: [tor-relays] Thailand block To: BRBfGWMz <brbfgwmz(a)concealed.company> I have been running an exit (mythaicontribution) in Thailand for 3 Years (the exit has narrow port 80 range but full 443 and all other less risky ports open. It has never been that busy as an exit, unlike my other UK and USA exits of similar profile. I noticed it was off line last week. The ISP was slow to work out what was going on, to discover that the upstream ISP has blocked the IP “due to DOS attack” I think that is unlikely for such a long block, and assume the hand of MICT. I gather the do not give reasons. (https://en.wikipedia.org/wiki/Internet_censorship_in_Thailand) In some ways surprising it took them so long. Is there a way on Tor’s web pages and data base to look at historical data. I am curious to know when it off line and removed from Tor metrics. Gerry \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online communication For everyone. https://www.msgsafe.io

2 1

Call for Testing - New Feature: Relay IPv6 Address Discovery
by David Goulet 28 Nov '20

28 Nov '20

Greetings everyone! We've very recently merged upstream (tor.git) full IPv6 supports which implies many many things. We are still finalizing the work but most of it is in at the moment. This is a call for help if anyone would like to test either git master[1] or nightly builds[2] (only Debian) to test for us a specific feature. The feature we would love for some of you to test is the IPv6 address discovery. In short, with this new feature, specifying an ORPort without an address will automatically bind tor to [::]:<port> and attempt to find the IPv6 address by looking at (in this order): 1. "Address" from torrc 2. "ORPort address:port" from torrc 3. Interface address. First public IPv6 is used. 4. Local hostname, DNS AAAA query. If all fails, the relay will simply never publish an IPv6 in the descriptor but it will work properly with the IPv4 (still mandatory). The other new thing is that now tor supports *two* "Address" statement which can be a hostname or IPv4 or IPv6 now. Thus this is now valid: Address 1.2.3.4 Address [4242::4242] ORPort 9001 Your Tor will bind to 0.0.0.0:9001 and [::]:9001 but will publish the 1.2.3.4 for the IPv4 address and [4242::4242] for IPv6 in the descriptor that is the address to use to reach your relay's ORPort. Now, if you happen to have this configuration which I believe might be common at the moment: ORPort 9001 ORPort [4242::4242]:9001 The second ORPort which specifies an IPv6 address will supersede the "ORPort 9001" which uses [::] and thus you will bind on 0.0.0.0:9001 and [4242::4242]:9001. You should get a notice log about this. Thus the recommended configuration to avoid that log notice would be to bind to specific addresses per family: ORPort <IPv4>:9001 ORPort <IPv6>:9001 And of course, if you want your relay to _not_ listen on IPv6: ORPort 9001 IPv4Only In your notice log, you will see which address is used to bind on the ORPort and then you will see the reachability test succeed or not on the address that tor either used from the configuration or auto discovered that is the address you are supposedly reachable from. Man page has NOT been updated yet, it will arrive once we stabilize the IPv6 feature and everything around it. Please, do report (on this thread) _anything_ even slightly annoying about this like logging or lack of logging and so on. This is a complex feature and errors can be made thus any testing you can offer is extremely appreciated. Thanks!! David [1] https://gitweb.torproject.org/tor.git/ [2] https://2019.www.torproject.org/docs/debian.html.en -- EeJVrrC/dHQXEXYB1ShOOZ4QuQ8PMnRY2XGq4BYsFq4=

8 12

Thailand block
by Dr Gerard Bulger 24 Nov '20

24 Nov '20

I have been running an exit (mythaicontribution) in Thailand for 3 Years (the exit has narrow port 80 range but full 443 and all other less risky ports open. It has never been that busy as an exit, unlike my other UK and USA exits of similar profile. I noticed it was off line last week. The ISP was slow to work out what was going on, to discover that the upstream ISP has blocked the IP "due to DOS attack" I think that is unlikely for such a long block, and assume the hand of MICT. I gather the do not give reasons. (https://en.wikipedia.org/wiki/Internet_censorship_in_Thailand) In some ways surprising it took them so long. Is there a way on Tor's web pages and data base to look at historical data. I am curious to know when it off line and removed from Tor metrics. Gerry

3 3

Fwd: Re: Bridges under DDoS
by William Kane 23 Nov '20

23 Nov '20

Forwarding to mailing list since OP has replied to my e-mail address, and not the list. ---------- Forwarded message ---------- From: William Kane <ttallink(a)googlemail.com> Date: Mon, 23 Nov 2020 16:07:39 +0000 Subject: Re: Re: [tor-relays] Bridges under DDoS To: BRBfGWMz <brbfgwmz(a)concealed.company> Dear BRBfGWMz, you can use this script I made a while ago - please read the entire message carefully or you risk locking yourself out of the system. Here you go: #!/bin/bash IPTABLES="/usr/sbin/iptables" # Flush all old rules and tables. $IPTABLES -F $IPTABLES -X $IPTABLES -t nat -F $IPTABLES -t nat -X # Establish default policies. $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT ACCEPT # Unconditionally allow local traffic. $IPTABLES -A INPUT -i lo -j ACCEPT # Allow already established connections. $IPTABLES -A INPUT -i <NETWORK_INTERFACE> -m state --state ESTABLISHED -j ACCEPT # Allow Tor ORPort traffic. $IPTABLES -A INPUT -i <NETWORK_INTERFACE> -p tcp --dport <YOUR_ORPORT> -j ACCEPT Note that this is for a normal Tor relay, not a bridge - for a bridge, just opening the inbound obfs4proxy port is enough, though. You will have to make adjustments, namely specifying the name of your public network interface ("ip addr" or "ifconfig", either one will work on modern distributions). Make sure to also open the port sshd, your SSH daemon, bound to or you will be locked out from the system after executing the script (!). If you are on Arch Linux, you can save the script to /etc/iptables/iptables.rules (execute the script and then run "iptables-save > /etc/iptables/iptables.rules", after that the only thing left to do is to enable the according systemd service unit to automatically load the rules on boot ("systemctl enable iptables"). If on Debian, you can specify a script to run as soon as your public network interface reaches the "up" state, directly in your network configuration. Note that this will just drop unknown incoming connections (ICMP traffic as well, so you won't be able to ping your server anymore), usually the best measure, you could also configure it to reject unknown TCP packets but this will generate additional outbound traffic (which is what an attacker might want). Please also note that if you are running a IPv6 enabled relay, you will have to use ip6tables instead of iptables - you will also have to allow all incoming ICMPv6 traffic through ip6tables, with plain IPv4 you don't really need to allow ICMP packets, with IPv6, it's absolutely required. Hope I helped, never be afraid to ask questions, I am here to help. 2020-11-22 21:12 GMT, BRBfGWMz <brbfgwmz(a)concealed.company>: > Are the locations for the relays that are set up during the process of > setting > up relays for a single machine truely random (or pseudorandom), or is there > any dependence on the ip/location of my desktop? > > On Tue, Nov 17, 2020 at 08:48 AM, William Kane <ttallink(a)googlemail.com> > wrote: > >> If your server is not responding, no harm done (likely already done if > >> you have iptables set up to drop unknown (established flag not set) > >> incoming traffic.). > >> > >> If it's somehow maxing out your connection speed, then time to talk to > >> your upstream provider / hosting company - very likely they already > >> have anti dos equipment on their network, and many would just re-route > >> a customer through it until the attack stops, but it might cost you > >> some money. > >> > >> 2020-11-13 17:03 GMT, Jonas <jonasdietrich(a)ctemplar.com>: > >> > According to packetflow traces, roughly 26,000 unique IPv4 from 85 >> countries > >> > executing a SYN flood attack on TCP/9001. None of my bridges have 9001 >> open > >> > nor respond to this port. The attacks continue to this day. > >> > > >> > Danke. > >> > > >> > Jonas > >> > _______________________________________________ > >> > tor-relays mailing list > >> > tor-relays(a)lists.torproject.org > >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >> > > >> _______________________________________________ > >> tor-relays mailing list > >> tor-relays(a)lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >> > > \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online > communication > For everyone. https://www.msgsafe.io > > >

1 0

Bridges under DDoS
by Jonas 14 Nov '20

14 Nov '20

Grüezi, Over the past seven days, all of my bridges are under DDoS attack. Other servers hosted with adjacent IP addresses are not under attack. Any one else seeing such attacks lately? Curious that all of my bridges are under attack, meaning someone altogether knows they exist. Thanks.

4 4

Re: [tor-relays] tor-relays Digest, Vol 118, Issue 16
by Mark Murray 13 Nov '20

13 Nov '20

I've been getting emails from OVH about "Detection of an attack" on my relays, it happened very occasionally but has been a bit more frequent recently. Anything I could/should do? Also is my first time replying to a mailing list ever, hopefully I replied to the right address? On 13/11/2020 12:00, tor-relays-request(a)lists.torproject.org wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: So my relay is apparently being attacked (Will Shackleton) > 2. Re: So my relay is apparently being attacked (Keifer Bly) > 3. Re: So my relay is apparently being attacked (Anders Burmeister) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 12 Nov 2020 19:16:25 +0000 > From: "Will Shackleton" <w.shackleton(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] So my relay is apparently being attacked > Message-ID: <3c5ee106-6233-4086-bd35-a445e8e6383e(a)www.fastmail.com> > Content-Type: text/plain > > My non-exit relays are being DDoS'ed too - I've received similar emails from my hosting provider. > > https://metrics.torproject.org/rs.html#search/family:B42C797CC8CD63C60FB643… > > -Will > > On Thu, 12 Nov 2020, at 7:09 PM, Roman Mamedov wrote: >> On Thu, 12 Nov 2020 10:52:47 -0800 >> Keifer Bly <keifer.bly(a)gmail.com> wrote: >> >>> I am wondering, are relays being ddosed a normal thing? Thank you. >>> --Keifer >> DDoS'ing opponents in an argument is common on some IRC networks, so it could >> have to do with the IRC exiting that you allow. >> >> I don't remember relays on their own getting DDoS'ed in years, but could >> remember a couple of cases of DDoS which could be correlated to IRC >> discussions I participated in right prior to that. >> >> -- >> With respect, >> Roman >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > ------------------------------ > > Message: 2 > Date: Thu, 12 Nov 2020 17:26:49 -0800 > From: Keifer Bly <keifer.bly(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] So my relay is apparently being attacked > Message-ID: > <CADqUGAO5udgNs6TF=McZemdRBLYVCXodcsi5RW0-PpbjZhXXnw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Thanks all. > --Keifer > > > On Thu, Nov 12, 2020 at 11:56 AM Will Shackleton <w.shackleton(a)gmail.com> > wrote: > >> My non-exit relays are being DDoS'ed too - I've received similar emails >> from my hosting provider. >> >> >> https://metrics.torproject.org/rs.html#search/family:B42C797CC8CD63C60FB643… >> >> -Will >> >> On Thu, 12 Nov 2020, at 7:09 PM, Roman Mamedov wrote: >>> On Thu, 12 Nov 2020 10:52:47 -0800 >>> Keifer Bly <keifer.bly(a)gmail.com> wrote: >>> >>>> I am wondering, are relays being ddosed a normal thing? Thank you. >>>> --Keifer >>> DDoS'ing opponents in an argument is common on some IRC networks, so it >> could >>> have to do with the IRC exiting that you allow. >>> >>> I don't remember relays on their own getting DDoS'ed in years, but could >>> remember a couple of cases of DDoS which could be correlated to IRC >>> discussions I participated in right prior to that. >>> >>> -- >>> With respect, >>> Roman >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >

1 0

So my relay is apparently being attacked
by Keifer Bly 13 Nov '20

13 Nov '20

Hi, So twice this week I've gotten this email from OVH: Dear Customer, We have just detected an attack on IP address 51.68.197.220. In order to protect your infrastructure, we vacuumed up your traffic onto our mitigation infrastructure. The entire attack will thus be filtered by our infrastructure, and only legitimate traffic will reach your servers. At the end of the attack, your infrastructure will be immediately withdrawn from the mitigation. For more information on the OVH mitigation infrastructure: http://www.ovh.com/world/anti-ddos/ Regarding the relay at https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… I am wondering, are relays being ddosed a normal thing? Thank you. --Keifer

6 7