störende IPs mit von Hand erstellte Regel (iptables) bannen?

S

stefkey

Member
Moin,

ich habe wieder ein paar Eps die ständig ein paar Seiten des installierten Forums aufrufen. Beeinträchtigen tut es eher nicht zur Zeit. Macht es Sinn die Eps einfach per IP-Tables auszuschließen? Wird der Angreifer dann nicht einfach andere Eps verwenden?

Hier die Ips sind es aktuelle:
45.225.71.198
45.229.168.65
45.229.168.68
45.229.168.69
45.229.168.71
45.229.168.72
 
Du könntest auch Subnets mit EINER Regel ausschließen:
45.229.168.* und die eine andere IP.

Je nachdem: wenn das dedizierte Server sind, dann können die die IP nicht ganz so einfach ändern. Wenns Dial-Up Verbindungen sind, dann sehr einfach. Da die IPs aber so nahe zusammenliegen, könnte ich mir durchaus vorstellen, dass das mehrere (befallene?) Server sind.
 
Ich habe wieder ein paar IPs die ständig ein paar Seiten des installierten Forums aufrufen.
Click to expand...

Die Frage ist, welches Ziel dahinter steht. Üblicherweise sind das Anmeldeversuche, die versuchen gültige Zugangsdaten für die Webanwendung zu erraten. Schau mal in Deine Webserverlogs, was der Angreifer wiederholt aufruft.

Macht es Sinn die IPs einfach per iptables auszuschließen? Wird der Angreifer dann nicht einfach andere IPs verwenden?
Click to expand...

Was den Fall des Erratens von Zugangsdaten betrifft: Meiner Erfahrung nach hat der Angreifer eine gewisse Menge an IPs und verteilt seine Angriffe dann auf die vorhandenen Quell-IPs. Das können auch schon mal sehr viele sein. Damit wird dann das Internet für eine Zeit lang abgegrast und vielleicht in späteren Versuchen werden nochmal andere IPs verwendet. Oder es kommt der nächste mit anderen IPs das gleiche versucht.

Da das heutzutage regelmässig passiert, ist es gut, das ganze automatisiert zu erkennen und abzublocken. Eine Möglichkeit ist es fail2ban auf das Webserverprotokoll anzusetzen, der nach einer gewissen Anzahl von Versuchen einzelne IPs einfach sperrt.
 
Ich würde an deiner Stelle (derzeit!) eine Regel für 45.229.0.0/16 erstellen.
Für diesen kompletten Präfix gibt es keine Zuteilungsdaten und auch momentan keine Routen mehr im Internet. Laut BGP-History tauchen allerdings hin und wieder sehr kurzzeitig und unvollständig Routen dazu auf, was den Schluss nahelegt dass diese IP-Adressen missbräuchlich geroutet und verwendet werden.

Du kannst diesen kompletten Präfix momentan reinen Gewissens sperren, solltest aber so in 2-3 Monaten nochmal nachprüfen ob die IP-Adressen nicht doch in der Zwischenzeit vergeben wurden.
 
Danke erstmal. Der Angreifer-Server scheint auch ein Problem mit dem SSL Zertifikat zu haben, denn im error.log stehen solche Zeilen (mit den unterschiedlichen o.g. IPs halt):

Code: 
[Sat Dec 31 22:19:17 2016] [error] [client 46.229.168.74] Re-negotiation handshake failed: Not accepted by client!?
 
Halt, warte...
Du hast im ersten Beitrag einen Zahlendreher. Bei 46.229.168.74 gilt meine Aussage nicht, dass diese eigentlich nicht existieren dürften und man sie daher reinen gewissens filtern kann.
Hier ist tatsächlich ein Hoster dahinter. Daher würde ich nur einzelne IP-Adressen, maximal jedoch /27-Präfixe blockieren wenn es zusammenhänge und aufeinanderfolgende Adressen sind.
 
Der besagte Hoster verstösst auch gegen die Erklärung die man bei RIPE abgeben muss, die Ressourcen nur in der RIPE Region zu nutzen. Das Netz scheint in US announced zu werden.
 
Diese Vorgabe ist WIMRE irgendwann mal abgeschafft worden. Jetzt ist es nur noch notwendig, dass sich der "Applicant" mit seinem Geschäftssitz in der RIPE-Region befindet, er darf das Netz aber advertisen wo es ihm gefällt.
 
Hm, stimmt wohl, aber als ich vor etwas mehr als einem Jahr LIR wurde, haben sie das noch ausdrücklich untersagt.
 

Attachments

  • Selection_171.png
    Selection_171.png
    41.5 KB · Views: 87
Achso, die Regelung gibt es noch immer.
Aber es entspricht den Regeln, wenn du z.B. einen Port am AMS-IX hast und darüber dein Netz mit-advertised. Dann hast du dein "active element inside the RIPE region". :rolleyes:
 
You must log in or register to reply here.
Back
Top