False-positive abuse reports from XMission's exit relay made against other relays
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. An ISP in Utah, XMission, runs their own Tor exit under the fingerprint E3DB2E354B883B59E8DC56B3E7A353DDFD457812. Their exit has been running for 14 whole years! But in the last few years, they appear to have added an AbuseIPDB auto-submitter script that reports any UFW blocks to AbuseIPDB, even if those come from fellow relays. I'm sure a lot of you have seen xmission appear as a reporter against your (middle and exit) relays on AbuseIPDB with a reports such as:
Blocked by UFW (TCP on 36972) Source port: 9001 TTL: 47 Packet length: 2276 TOS: 0x08 This report (for 89.125.139.145) was generated by: https://github.com/sefinek/UFW-AbuseIPDB-Reporter
I've tried contacting their support and they may be slowly realizing what the issue is, but I (and others) have already had relays suspended by our hosting providers because of XMission's false reports, and they do not appear to be doing anything about it anytime soon. What can be done about this? At this rate, I'll have to shut a number of my own relays down because of their false reports. The only other thing I can think of is to block their IP, but I know that that's not good practice. Is it a necessary evil in this case? Could someone from Tor Project possibly reach out to them and explain that their relay is auto-submitting false positive abuse reports against other relay operators, if I'm unable to get through to them? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCao5ARwAKCRAw+TRLM+X4 xsRVAP9nr/n4linFzJDSDnayuR4z8ZI83E7UsT6Mx1W4v+1fLQEA8vfxAOQm1R+2 liyMtXCw/cEyvUFto+1m0TBZMUaPywI= =gyrl -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I've gotten in contact with the XMission support and they said they'll escalate it to their networking team who operates the relay. In the meantime, I know it's not the best practice but as the alternative is losing several of my relays, I've had to block the IPs of their exit: nft insert rule inet filter input ip saddr 166.70.207.2 counter drop nft insert rule inet filter input ip6 saddr 2607:fa18:3:beef:f001:c0de:feed:ba5e counter drop nft insert rule inet filter output ip daddr 166.70.207.2 counter drop nft insert rule inet filter output ip6 daddr 2607:fa18:3:beef:f001:c0de:feed:ba5e counter drop Hopefully I'll be able to get in contact with the person specifically responsible for this relay, since they'll be more understanding. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCao5IOgAKCRAw+TRLM+X4 xuJdAP9yeVYFYoDQY/dnOYPLgYMyJhLxM6/iuPakUX0vLFRFKAEA7YTvAxo53/tR w047pRbzlWJF9+Da43EL+okDYcx6dww= =+LGa -----END PGP SIGNATURE-----
participants (1)
-
forest-relay-contact@cryptolab.net