Seitenstatistik

S

siggi67

New Member
Hallo,

mal eine Frage:
In der Seitenstatistik der Domains auf dem Server erscheine plötzlich folgenden
Dateien, die anscheind aufgerufen wurden, oder hat das einen anderen Huntergrund das diese Daten dort plötzlich auftauchen?

Hier mal die Dateien:
> /phpAlbum/main.php 10 -
> /main.php 10 -
> /scripts/awstats.pl 10 -
> /cgi/awstats/awstats.pl 10 -
> /stats/awstats.pl 10 -
> /cgi-bin/awstats.pl 10 -
> /scgi-bin/awstats/awstats.pl 10 -
> /apps/phpAlbum/main.php 10 -
> /scgi-bin/awstats.pl 10 -
> /phpalbum/main.php 10 -
> /cgi-bin/stats/awstats.pl 10 -
> /cgi-bin/awstats/awstats.pl 10 -
> /awstats/awstats.pl 10 -
> /scgi-bin/stats/awstats.pl 10 -
> /scgi/awstats/awstats.pl 10 -
> /stat/awstatstotals.php 9 -
> /awstatstotals.php 9 -
> /apps/phpalbum/main.php 9 -
> /awstatstotals/awstatstotals.php 9 -
> /awstats/awstatstotals.php 9 -
> /site.php 6 -
> /index.php 6 -
> //php-my-admin/index.php 2 -
> //phpMyAdmin/index.php 2 -
> //phpmyadmin/index.php 2 -
> //phpMyAdmin-2.5.6-rc2/index.php 1 -
> //phpMyAdmin-2.5.5-pl1/index.php 1 -
> //web/phpMyAdmin/index.php 1 -
> //phpMyAdmin-2.5.7-pl1/index.php 1 -
> //dbadmin/index.php 1 -
> //myadmin/index.php 1 -
> //mysqladmin/index.php 1 -
> /muieblackcat 1 -
> //phpMyAdmin-2.5.1/index.php 1 -
> //phpMyAdmin-2.5.4/index.php 1 -
> //phpmyadmin1/index.php 1 -
> //web/index.php 1 -
> //admin/pma/index.php 1 -
> //index.php 1 -
> //phpMyAdmin-2.2.3/index.php 1 -
> //phpMyAdmin-2.5.6/index.php 1 -
> //pma/index.php 1 -
> //phpmyadmin2/index.php 1 -
> //typo3/phpmyadmin/index.php 1 -
> //phpMyAdmin-2.5.6-rc1/index.php 1 -
> //phpadmin/index.php 1 -
> //xampp/phpmyadmin/index.php 1 -
> //phpMyAdmin-2.5.5/index.php 1 -
> //phpMyAdmin-2.5.5-rc1/index.php 1 -
> //phpMyAdmin-2/index.php 1 -
> //phpMyAdmin-2.5.5-rc2/index.php 1 -
> //phpMyAdmin-2.2.6/index.php 1 -
> //phpMyAdmin-2.5.7/index.php 1 -
> //websql/index.php 1 -
> //admin/phpmyadmin/index.php 1 -
> //db/index.php 1 -
> //admin/index.php 1 -
> //mysql/index.php


Danke
 
Da wurde einfach ein Bot bzw. Crawler auf deine Domain losgelassen und hat nachgesehen, ob du einen der „üblichen Verdächtigen” laufen hast, den man ausnutzen könnte.

Willkommen im Internet. ;)
 
Das unterdrücken mit fail2ban ist aber auch eher Kosmetik für die Logs, sofern die Dateien nicht existieren, gibt es einen resourcenschonenden 404-Fehler, wenn wirklich eine anfällige Version existiert, hilft nur eins: Updaten oder wenn es keine Updates mehr gibt, auf eine Alternative umstellen.
 
danton said:
Das unterdrücken mit fail2ban ist aber auch eher Kosmetik für die Logs, sofern die Dateien nicht existieren
Click to expand...

na ja kosmetik ist das eigentlich nicht, das ist ja schliesslich komplettes
blocken der ip für einen längerungen zeitraum.
ausserdem ist das blocken der ip auf kernel ebene schneller als das
durchreichen an den webserver, der dafür einen thread öffnen muss
und ins logfile schreiben muss.

ausserdem hast du damit schneller ruhe, gerade bei denen die nicht nur nach
einer schwachstelle suchen.

also mir geht sowas schon auf die nerven. wenn du ohne fail2ban über
2 Mio 404 meldungen von bots im log hast die nach schwachstellen in
programmen suchen die sowieso nicht auf dem webserver laufen.

da lass ich doch lieber die arbeit von fail2ban machen wenn da son
bot mit 20 verbindungen gleichzeitig versucht meinen apachen zu nerven.

Sven
 
Fail2Ban hat noch einen großen Vorteil, sofern man Fail2Ban zum Beispiel mit blocklist.de verknüpft.

Dann "reportet" man die Angriffe und kann da durch seinen kleinen Beitrag leisten, dass Internet ein wenig sicherer zu machen.
 
Updaten oder wenn es keine Updates mehr gibt, auf eine Alternative umstellen.
Click to expand...
Oder wenn das nicht machbar ist mit entsprechenden mod_security Regeln die Angriffsflaeche blockieren.
(mod_rewrite tut's auch wenn man nur einzelne Datei-Parameter gezielt sperren muss, ist aber bedeutend weniger flexibel)
 
Sven_R said:
ausserdem ist das blocken der ip auf kernel ebene schneller als das
durchreichen an den webserver, der dafür einen thread öffnen muss
und ins logfile schreiben muss.
Click to expand...
Und das Parsen der Logs durch fail2ban und der Regeln durch IPTables geht schneller und ressourcenschonender? Sorry, aber das bezweifle ich...

Sven_R said:
also mir geht sowas schon auf die nerven. wenn du ohne fail2ban über
2 Mio 404 meldungen von bots im log hast die nach schwachstellen in
programmen suchen die sowieso nicht auf dem webserver laufen.
Click to expand...
Die lassen sich bei Bedarf auch während der Logauswertung ausfiltern, bleiben aber für etwaige forensische Auswertungen erhalten. Letzteres ist rechtlich durchaus wichtig.

its said:
Fail2Ban hat noch einen großen Vorteil, sofern man Fail2Ban zum Beispiel mit blocklist.de verknüpft.

Dann "reportet" man die Angriffe und kann da durch seinen kleinen Beitrag leisten, dass Internet ein wenig sicherer zu machen.
Click to expand...
Prima, noch mehr Spam für die Abuse-Desks, die haben ja sonst nix zu tun...
 
Und das Parsen der Logs durch fail2ban und der Regeln durch IPTables geht schneller und ressourcenschonender?
Click to expand...
fail2ban muss die Logs ja nicht in Echtzeit analysieren und nachdem er eine IP gebannt ist kriegt er weniger Logs. Apache muesste fuer jede 404 eine Schreibaktion durchfuehren, seine unzaehligen Module und Funktionen aufrufen, undundund.

Iptables ist richtig fix, aber man sollte eine Chain fuer TCP-Verbindungen auf Port 80 im SYN-Status anlegen um nicht _ALLE_ Verbindungen durch die DROP-Liste zu jagen.

Die lassen sich bei Bedarf auch während der Logauswertung ausfiltern, bleiben aber für etwaige forensische Auswertungen erhalten. Letzteres ist rechtlich durchaus wichtig.
Click to expand...
Etwas was nie geschieht muss auch nie analysiert und ausgewertet werden. Wenn nie eine Verbindung zustande kommt kann er nie einen Exploit versuchen.

Prima, noch mehr Spam für die Abuse-Desks, die haben ja sonst nix zu tun...
Click to expand...
Scheinbar nicht, sonst haetten die ISP's bessere Systeme zur Erkennung von Missbrauch.
 
d4f said:
fail2ban muss die Logs ja nicht in Echtzeit analysieren
Click to expand...
Wie lange dauert das Abgrasen der typischen Installationsverzeichnisse der zu attackierenden WebApps? Wenige Sekunden und danach ist wieder Ruhe. Was bringt dann ein fail2ban das nicht in Realtime die Logs parst, sondern erst wenn es zu spät ist?

d4f said:
und nachdem er eine IP gebannt ist kriegt er weniger Logs.
Click to expand...
Wohl kaum, siehe oben.

d4f said:
Apache muesste fuer jede 404 eine Schreibaktion durchfuehren, seine unzaehligen Module und Funktionen aufrufen, undundund.
Click to expand...
Lies den Quelltext nochmal, die Logs werden beim Starten von Apache geöffnet und bleiben es bis zum Stoppen des Apache.

d4f said:
Iptables ist richtig fix, aber man sollte eine Chain fuer TCP-Verbindungen auf Port 80 im SYN-Status anlegen um nicht _ALLE_ Verbindungen durch die DROP-Liste zu jagen.
Click to expand...
Wenn IPTables so fix wäre, bräuchte man die zusätzliche Chain nicht.

d4f said:
Etwas was nie geschieht muss auch nie analysiert und ausgewertet werden. Wenn nie eine Verbindung zustande kommt kann er nie einen Exploit versuchen.
Click to expand...
Die Verbindung kommt immer zu Stande, wie sollte IPTables sie sonst DROPen können?

d4f said:
Scheinbar nicht, sonst haetten die ISP's bessere Systeme zur Erkennung von Missbrauch.
Click to expand...
Ahja, da Du ja als Hoster auftrittst: Wie willst Du Missbrauch nachweisen, wenn Du mit Deinem IPTables-Voodoo bereits die Beweise manipulierst beziehungsweise gar zerstörst? Willst Du wirklich automatisiert mit falschen Abuse-Meldungen überschwemmt werden? Ein Script mit Deinen IPs als Source ist schnell aufgesetzt und die Miete für ein entsprechendes Botnet ist lächerlich gering...
 
Was bringt dann ein fail2ban das nicht in Realtime die Logs parst, sondern erst wenn es zu spät ist?
Click to expand...
Es bringt dass der Besucher ein Hausverbot der Art "iptables DROP" kriegt und somit keine weiteren Ressourcen belasten kann und auch den Server nicht weiter nach exploitbarer Software durchsucht.
Zur Blockierung von Exploits ist ja Fail2ban gaenzlich ungeeignet, hierzu gibt es mod_security. Dessen Log-Dateien kann man uebrigens auch ganz praktisch in Fail2Ban fuettern, da man zB mit dne GotRoot Regeln so ziemlich alle Exploit-Versuche erkennt.

Lies den Quelltext nochmal, die Logs werden beim Starten von Apache geöffnet und bleiben es bis zum Stoppen des Apache.
Click to expand...
Dazu muss man nicht den Quelltext lesen, die Dokumentation reicht :cool:
Wieso das was mit Schreiboperationen zu tun hat ist mir aber zweifelhaft, egal ob die Datei offen oder zu ist, schreiben kostet immer...

Wenn IPTables so fix wäre, bräuchte man die zusätzliche Chain nicht.
Click to expand...
Nur weil etwas schnell ist muss man nicht unnoetig Ressourcen verschwenden. Ungebremst ist noch immer schneller als die schnellste Zwischenstufe.
Wir reden ja hier auch nicht von einer Dutzend Regeln und einer Dutzend Verbindungen, auf einem ausgelasteten Rootserver macht es schon Sinn ueberall zu sparen wo man kann.

Die Verbindung kommt immer zu Stande, wie sollte IPTables sie sonst DROPen können?
Click to expand...
Eine offene Verbindung ist eine die durch den 3-Way Handshake gelaufen ist (SYN-SYNACK-ACK), wenn du sie nie ueber SYN rauslaesst ist sie nichtmal halboffen (das setzt schliesslich ein SYNACK voraus).

Wie willst Du Missbrauch nachweisen, wenn Du mit Deinem IPTables-Voodoo bereits die Beweise manipulierst beziehungsweise gar zerstörst?
Click to expand...
Gegenfrage: Welchen Missbrauch willst du ueberhaupt nachweisen wenn der Angreifer bereits vorher gestoppt wurde? Missbrauch setzt ja voraus dass er erfolgreich war und das wiederum setzt voraus dass er nicht gestoppt wurde.
Nach deiner Logik muss man Tuer und Tor offen lassen da sonst kein Missbrauch nachgewiesen werden kann. Klar, sonst waere ja auch keiner moeglich...

Wenn aber bereits jemand erfolgreich eingedrungen ist (also an iptables + mod_security + CXS vorbei gekommen ist) dann vernichtet ein "iptables DROP" seine Spuren nicht sondern hindert ihn nur daran weiteren Schaden -und somit Spuren- zu machen.

Willst Du wirklich automatisiert mit falschen Abuse-Meldungen überschwemmt werden?
Click to expand...
Mich wuerde interessieren wie du TCP-Verbindungen in einem gerouteten Netzwerk eines Rechenzentrums spoofen willst, schliesslich musst du die RZ-internen Router, Carrier-Router und Provider-Router dazu ueberlisten alle Pakete zurueck an dich zu schicken. Das ist eins der Hauptgruende warum jeder Sysadmin stateful connections liebt.
Abuse-Meldungen fuer HTTP-Traffic sind also nicht 'falsch' als dass sie eine andere IP betreffen sollten, sie koennen nur unzureichend, erfunden oder unbegruended sein.

die Miete für ein entsprechendes Botnet ist lächerlich gering...
Click to expand...
Ein Grund mehr auf iptables-Blocking statt Apache 404 zu setzen. Apache schafft es nicht mal ein entsprechendes Botnet zu beliefern, Iptables haelt dabei sein Mittagsschlaf.
 
Joe User said:
Und das Parsen der Logs durch fail2ban und der Regeln durch IPTables geht
schneller und ressourcenschonender? Sorry, aber das bezweifle ich...
Click to expand...

das parsen und daraus aufbauende iptables regeln geht auf die dauer gesehen
schneller als das der webserver einen prozess für jede verbindung erzeugt
und dann eine 404 liefert und danach den speicher weider leerräumt.

Joe User said:
Wie lange dauert das Abgrasen der typischen Installationsverzeichnisse
der zu attackierenden WebApps?
Wenige Sekunden und danach ist wieder Ruhe.
Click to expand...
das hab ich noch nie gesehen das EIN bot EINMAL drüberläuft!!!!
wenn ich bei mir fali2ban abschalte hab ich meist mehr bots als besucher auf
meinen servern!! die geben sich die klinke in die hand, meist kommen die auch
gleich mit 20 oder 30 verbindungen gleichzeitig rein!!

da ist es ressourcen schonender EINMAL fail2ban temporär die ip sperren zu lassen
und dann gleich 20 % prozent weniger apache prozesse zu haben!!


Joe User said:
Die Verbindung kommt immer zu Stande, wie sollte IPTables sie sonst DROPen können?
Click to expand...
aber die bleibt auf kernel ebene hängen und wird nicht in den user space an
apache weiter gereicht.

Sven
 
You must log in or register to reply here.
Back
Top