Speziell Zugriffe, die von einem Webhoster ausgehen, kann man eigentlich fast immer blockieren. So gut wie kein legitimer Besucher einer Seite ruft die Seite über einen Server bei einem Webhoster ab, solche Zugriffe erfolgen in aller Regel über reguläre Internetzugänge. Eine Ausnahme bilden Suchmaschinen-Bots wie z. B. Google, Bing u. a. Diese Bots laufen üblicherweise auf Webservern, aber man sollte sie trotzdem nicht blockieren, sonst verschlechtert man das Suchmaschinen-Ranking seiner Seite. Ob ein Zugriff von einem Suchmaschinen-Bot kam, erfährt man aus den "User Agent"-Einträgen in den Server-Logs.

Um zu entscheiden, wie mit unerwünschten Zugriffen zu verfahren ist, werfe ich die IP zunächst bei Ripe (https://stat.ripe.net/) ein. Dort erfahre ich, wem die IP gehört und zu welchem IP-Range sie gehört. Beispiel 54.36.148.14: https://stat.ripe.net/54.36.148.14#tabId=at-a-glance sagt mir, dass die IP zu OVH gehört. Das ist ein französischer Webhoster, wobei die IP offenbar zu einem dedicated server gehört (siehe "netname"-Eintrag). Das lässt auf einen Zugriff schließen, der nicht von einem regulären Besucher der Seite kam. Weiterhin erfahre ich aus dem Reverse DNS-Eintrag, dass über diese IP der Ahrefs-Bot auf die eigene Seite zugreift (wie oben geschrieben kann man das auch am User Agent-Eintrag in den Server-Logs erkennen). Der Ahrefs-Bot ist kein Suchmaschinen-Bot und hat in der Regel auch sonst keinen Nutzen, also kann er geblockt werden. Sinnvollerweise blockiert man den kompletten IP-Range, zu dem die fragliche IP gehört. Auch diesen erfährt man auf der RIPE-Seite, es ist 54.36.148.0/22. Man trägt also folgendes in die .htaccess ein:

deny from 54.36.148.0/22

Und schon hat man Ruhe vor einer ganzen Reihe von OVH-IPs. Leider ist das aber nur ein winziger Bruchteil der IPs, die man eigentlich blocken könnte. Es braucht also sehr viele "deny from"-Einträge in der .htaccess. Die .htaccess für einen Webauftritt, den ich betreue, ist daher im Lauf der Zeit schon über 20 KB groß geworden😉

Nachtrag: .htaccess gibt es nur auf Apache-Servern. Andere Server (z. B. nginx oder Microsoft IS) können zwar auch IPs blocken, die dafür erforderlichen Maßnahmen unterscheiden sich aber von denen bei Apache-Servern. Ich weiß nicht, ob bei den Telekom-Homepages Apache zum Einsatz kommt. Die Wahrscheinlichkeit ist aber groß, denn Apache ist ein sehr verbreiteter Server.

@Sonnenhügler_1 
Wie kommst du auf die 54.36.148.0/22 ?

Laut Online Subnet Calculator (http://www.subnet-calculator.com/subnet.php?net_class=A) müsste der Eintrag so aussehen:

54.36.148.0/15

Dann wird von 54.36.148.0 bis 54.36.149.255 alles ausgesperrt.
Bei t-online läuft Apache Server. .htaccess scheint aber nicht zu funktionieren.
Ich versuche mich mal selbst auszusperren, hab ja dann immer noch den FTP Zugang.

Die /22 habe ich auf der RIPE-Seite nachgelesen. Mit /15 wäre ich vorsichtig, denn dann könnten IPs blockiert werden, die man gar nicht blockieren will. Lieber für die 2. IP einen zweiten deny-Eintrag anlegen. Auch dafür kann man den IP-Range wieder bei RIPE erfragen.

Hab Alles so eingerichtet, leider ohne Erfolg

Mein Spamhaus Modul zeichnet immer noch Zugriffe von den in der .htaccess eingetragenen IP's auf.

10/02/2020 11:56:38 am - 54.36.148.98 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.148.98 for details.
10/02/2020 11:56:39 am - 54.36.148.239 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.148.239 for details.
10/02/2020 11:56:42 am - 54.36.148.239 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.148.239 for details.
10/02/2020 11:56:45 am - 54.36.149.39 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.149.39 for details.
10/02/2020 11:56:50 am - 54.36.148.195 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.148.195 for details.
10/02/2020 11:56:51 am - 54.36.149.2 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.149.2 for details.
10/02/2020 11:56:54 am - 54.36.149.92 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.149.92 for details.
10/02/2020 11:56:55 am - 54.36.148.239 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.148.239 for details.
10/02/2020 11:56:58 am - 54.36.148.59 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.148.59 for details.
10/02/2020 11:57:00 am - 54.36.148.239 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.148.239 for details.
10/02/2020 11:57:04 am - 54.36.148.236 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.148.236 for details.
10/02/2020 11:57:04 am - 54.36.148.199 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.148.199 for details.
10/02/2020 11:57:08 am - 54.36.148.34 was blocked, see http://www.abuseat.org/lookup.cgi?ip=54.36.148.34 for details.

Ich würde erst einmal testen, ob die .htaccess überhaupt funktioniert. Dazu kann man einen deny-Eintrag mit der eigenen IP anlegen (die wiederum kann man z. B. auf https://www.heise.de/netze/tools/meine-ip-adresse/  herausfinden). Ein anschließender Versuch, auf die Seite zuzugreifen, müsste dann mit einem 403 "Access denied" quittiert werden. Die Seite selbst bzw. dort installierte Module dürften diesen Zugriff gar nicht bemerken, da er bereits vom Server geblockt wird.

@Quarx 

Bitte liste uns mal die Einträge Deiner htaccess auf.

Der Fehler steckt manchmal im Detail.