Bots

[toosten]

Ich lagere das mal aus, weil es hat weniger mit PHP zu tun.

ich weiß nicht was du für angriffe meinst, dein ding.
ob du es für sinvoll erachtets dien konzeption hier diskutiren oder nicht, auch dein ding.
es gibt im netz genügend diskussionen dazu, und du bsit wedere der TE, noch ist dies thema.

du hast dich bei headless eingeschaltet, und es ging um die frage, ist es einfach einen useragnet string bei headless zu faken ?

scheint mir schon:

https://github.com/ultrafunkamsterda...d-chromedriver

und ja fingerprint faking und zeugs findet man auch.

und wenn dir das alalles zu stressig ist, registriere dich mit "free trial" bei einem namhaften crawling unternehmen - auch als script kid.,

Wir bieten einen Online-Service an bei dem sich User bei uns registrieren können und wenn ihnen der Dienst gefällt ihn buchen können.

Somit benötigen wir ein Loginsystem, mit möglichst wenig Fehlanmeldungen und Loginversuchen seitens Bots/ScriptKiddies.

Vermutlich hat der Vorbesitzer der Domain auch ein Login benötigt und dieser Login scheint in irgend einer Liste zu sein, jedenfalls haben wir auf www.domain.de:80/platform/login sehr viele Anfragen.
Diese liegen zwischen wenigen Minuten bis einmalig. Die Penetranten sind vorrangig Server-IPs, die einmaligen sind vorrangig ISPs.

Und weil mich dieser Traffic stört, hatte ich angefangen diese per Hand zu blockieren. Es hörte aber nicht auf, somit habe ich dies automatisiert.
Am Anfang hab eich diese auf unser SSL-Login umgeleitet, war sinnlos das keine User.
( hier finde ich erstaunlich das sich diese URL über viele Jahre noch immer so stark abgefragt wird )

Des weiteren gibt es von diversen IPs und Subnetzen, Penetrationsabfragen über alle genutzten Domains. Hier gibt es jetzt ach eine Negativliste, welche zur automatischen Sperrung führt.

Das schützt natürlich nur vor Traffic, aber stört/verzögert auch ein wenig beim Durchtesten was auf dem Server installiert bzw. genutzt wird.

Bis vor einiger Zeit konnte man mit Hiddenfeldern und ein wenig Javascript zwischen Mensch ( mit Javascript ) und curl-Bots problemlos unterscheiden.
Das hat der HeadlessChrome geändert, weil diesen kein User wegen der fehlenden GUI nutzen wird, kann man diesen Problemlos blocken.

Jedenfalls ist die Anzahl der täglichen 404 Statuscodes enorm zurück gegangen und wieder übersichtlich, auch Javascript-Fehlermeldungen sind selten geworden und die Anzahl der Registrierungen wieder auf einem normalem Niveau.

Somit gibt es weniger zu begutachten und man hat wieder mehr Zeit für Weiterentwicklungen.

Bei einem Hacker für Anfängerkurs hatte das vorgehen von ScriptKiddies kennen gelernt, der CCC hat auch schon mehrere male erläutert, wie man ein System hackt.
Dieses zeitnahe sperren von IPs, verzögert diese Aktivitäten enorm.

Aber wenn man Lücken hat, reicht das Verzögern nicht, man muß diese schließen.

Nebenbei ist es interessant, was alles gesucht wird, man kann also auch lernen was andere so falsch machen.
Denn irgendwann muß es ja mal geklappt haben und nicht nur bei einem Server.

P.S. Beim 38C3 gab es einen Vortrag zu einem FakeShopsystem, dieses hatte sein Git-Repository in der DocumentRoot, somit konnte man es ohne Passwort durchsuchen und natürlich enthielt es auch die Zugangsdaten für die Datenbank.

[tomBuilder]

Das Internet ist kein so freundlicher Ort wie er einst war, oder als was es gedacht war.

Da gilt es sich anzupassen, wenn möglich auf jeder ebene .

Ein kleines nette Buch zum Einstzeiogen findet sich hier:_

https://www.feistyduck.com/library/a...curity/online/

und ja, es ist von 2021

[toosten]

Das Internet war bei meinem Start vor Jahrzehnten schon ein Ort der Hacker. Aber ja, diese Anpassung ist jetzt in dieser dynamischen Nutzung von iptables gelandet.

Eventuell bin ich nur ein wenig paranoider und mag nicht den Traffic der "ScriptKiddies" finanzieren zu wollen.

Es kann halt jeder am INet befindliche Rechner auf den Webserver zugreifen, aber einige tun das halt nicht mit guter Absicht - das verhindern wir jetzt automatisch.

Aktuell gehen wir auf die 10k IPs & Subnetze zu, weil ~50 IPs pro Tag mehr gesperrt werden als wieder unter Beobachtung freigegeben werden.

Heute Nacht ist wieder mal ein Subnet-24 automatisch geblockt worden, innerhalb von Minuten viele 404-Abfragen von über 20 IPs aus diesem Subnet.

Normale Besucher merken es gar nicht, denn diese nutzen nur die bekannten Links.


P.S. Um ein wenig den Umfang zu beschreiben, als wir dieses System noch nicht hatten, gab es folgende aufgefallene Extremabfrage:
Von der selben IP gab es auf einer Domain 18275 unsinnige GET bzw. POST innerhalb von 200 Sekunden - diese IP ist jetzt nach wenigen Sekunden gesperrt.

Das ist inzwischen fast täglich so gewesen, manchmal spielten da ganze Subnetze über mehrere Domains gleichzeitig mit.

[tomBuilder]

ich persöhnlich bin wenig freund davon privilegien in der administration zu vermischen.
iptables ist uid0 und sollte mE erstmal nicht mit einer aplication zu tun haben.

meriner ansicht nach wäre da bspw mod_Security ein besseres werkzeug, inclusive zugang zu rbls etc

aber das ist nur meine prsöhnliche meinunfg

[toosten]

Danke, werde ich mir ansehen.

P.S. Ja, da bin ich schon mal drüber gestolpert, mod_Security schien mir zu Ressourcenhungrig, weil ja die IPs nicht komplett geblockt wird, sondern bei jeder Anfrage die Sec-Regeln durchlaufen werden.

Da finde ich meinen Ansatz besser, denn ich schaue vor allem auf die 404-Fehler und blocke die IP dann für eine Weile.
Im Gegensatz blockt mod_Security die IP nicht, sondern reagiert auf jede Anfrage neu.

Auf einen Bot, welcher sich die Domains einer IP holt und dann alle jeweils mit 10k Anfragen beglückt, denn sperre ich lieber bei der ersten aus.

[reddighamburg]

welcher sich die Domains einer IP holt

Das kann ein Bot aber nur dann, wenn diese irgendwo veröffentlicht sind. Das zeugt dann von grauenhaft unsicheren DNS oder einem sonstigen Leck.

Der Bot kann natürlich PTR records abfragen, aber die zeigen normalerweise nicht auf einen Domainnamen einer Webseite. Oder er holt sich ganze Zonen per Transfer, was ihm eigentlich verboten sein sollte. Oder er cached tausende von regulären DNS Anfragen auf möglicherweise bereits kompromittieren Geräten.
Im schlimmsten Fall ist der Host oder ein Router auf dem deine Dienste laufen kompromittiert und der Bot hat Zugriff auf Daten, die er eigentlich nicht haben sollte.

Wenn du derartige Angriffe bemerkst, solltest du zumindest einmal nachsehen, woher der Bot die Domainnamen erhalten haben könnte, denn per einfachem forward DNS Lookup funktioniert das nur in die andere Richtung.

[toosten]

Das kann ein Bot aber nur dann, wenn diese irgendwo veröffentlicht sind. Das zeugt dann von grauenhaft unsicheren DNS oder einem sonstigen Leck.

Es gibt diverse Dienste, welche die Domains einer IP sammeln und per IP dann ausgeben.

Bsp: https://www.ip-von-domain.de/domains-von-ip-ermitteln
umfangreicher: https://dnslytics.com/reverse-ip/

[tomBuilder]

klar alles kostet performance , und in diese modsec dingens muss m,an sich erstmal einlesen, das ganze sinvoll aufsetzen, sich übnerlegen ob man das mit ML empowern möchte,
und irgewndwann merkt man, für en paar script kieddies ist das alles overengenierd.

https://medium.com/@ariudvd/the-rise...d-f7fcd3e6d3e2

[toosten]

mod_security geht mir nicht weit genug, da muß ich mich gar nicht weiter einlesen. Hier wird jede Datei analysiert, das ist zuviel des guten.

Um zu sehen, das jemand Dateien ausschließlich außerhalb der Vorgaben sucht, dafür brauche ich kein ML.
Und wenn man sein Universum bzgl. Parametern nicht überfrachtet, brauch man auch kein ML.

Man muß sich z.B. nur ins "ErrorDocument 404" hängen und wenige Filter auf gewisse Dateitypen:

// BLACKLIST
            $a= array(  ".php", ".cgi", ".bas", ".asp", ".aspx", ".jsp", ".bak", ".ashx", ".php6", ".php7", ".php8", ".alfa", ".asmx", ".dll",
                        ".env", ".remote", ".local", ".production", ".alfa",  ".yml", ".key",
                        ".rar", ".7z", ".gz", ".zip",
                        ... 

Wer so etwas sucht und nicht findet, macht eine Pause, Wiederholungstäter immer länger.
Ob das nun ScriptKiddies oder Bots sind ist egal, beide werden mein Business nicht nutzen wollen und ich werde sie nicht vermissen.

Und wenn es wieder neue 404er gibt, kann man diese hinzufügen - sollte man eh ab und zu durchsehen.

Nebenbei, auch nach dem Sperren hören viele IPs nicht auf, werden aber durch iptables geblockt und der apache merkt davon nix.
Hingegen würde mod_security jede Abfrage neu bewerten und somit ein Vielfaches an CPU-Zeit kosten und mehr Traffic kosten.