[Eisfair] [e1] mehrere "Zicken" mit BFB 0.8.3

Sa Jan 21 14:53:26 CET 2017

Hallo an alle,

und hallo an Olaf, ich hoffe Du konntest Dich von Deinen privaten
Problemen schon ein wenig frei machen. Wir arbeiten noch intensiv daran
aber haben zumindest den schweren Gang hinter uns.

Ich habe mich die Tage mal etwas intensiver mit den Problemen bei BFB
beschäftigt die unter "BFB 0.8.3 immer noch Problem mit *.html" in s.e.d
aufgeführt sind, und einige Punkte zusammengetragen.
Es ist leider etwas länger geworden aber heute kam noch etwas dazu.

Die Ursache für das Problem mit den "verstümmelten" Dateinamen konnte
ich ja bereits finden. Es scheint wohl mit der "Navigationshilfe" der
Telekom zusammen zu hängen wie in "[Gelöst] Re: BFB 0.8.3 immer noch
Problem mit *.html" unter s.e.d zu lesen ist.

Das nächste Problem ist, dass die Dateien
$cgi_dokumentroot/brute_force_blocking.cgi und
$apache_documentroot/brute_force_blocking.html nicht mehr angelegt werden.

Ich habe es dahingehend noch einmal verifiziert, dass ich unter
Virtualbox einen "sauberen" Eisfair installiert habe. Base und Kernel
auf den aktuellen Stand gebracht habe und bis auf Apache mit den nötigen
Paketen und BFB nichts installiert habe. Auch dort wurden diese Dateien
nicht angelegt.
Es ist solange wohl nicht aufgefallen, weil diese Dateien von einer
älteren Version installiert wurden und eben schon da waren.
Dazu ist mir übrigens im Deinstall-Script aufgefallen, dass diese beiden
Dateien nicht gelöscht werden da im Fall der
$apache_documentroot/brute_force_blocking.html diese dort gar nicht
aufgeführt und im Falle der $cgi_dokumentroot/brute_force_blocking.cgi
diese dort mit einem falschen Namen angegeben ist.

rm -f /var/www/cgi-bin/brute_force_attacks.cgi

Angelegt sollen die Dateien wohl mit dem Script brute_force_blocking_web
werden welches auch schon in der Version 0.7.4 unverändert so vorliegt.
Im Script fällt mir nichts auf, ich habe aber auch nicht so viel Ahnung.

Hat jemand evtl. noch eine ältere Version von BFB da?
Ich konzentriere mich immer auf die Veränderungen zu einer Version in
der es noch funktionierte um das Problem zu ergründen.

Dann waren da die beim unblocking nicht mehr abgeräumten *.html Dateien.
Ich habe das mal mit der Version 0.7.4 verglichen.

0.7.4
rm -f $apache_documentroot/$index_folder/*.*.html

0.8.3
cd $apache_documentroot/$index_folder
for FNAME in `ls -t| grep html|tail -n +11`
do
    rm -f $FNAME
done

Die Frage für mich ist dabei, im (derzeit nicht erstellten)
brute_force_attacks.cgi sehe ich bei den älteren Versionen von BFB die
IPs gelistet die aktuell gesperrt sind und derzeit bis zu zehn, die
längst nicht mehr geblockt sind da derzeit alle _außer_ den 10 neuesten
gelöscht werden. Hinzu kommt, da das Script removehtmlfiles  nicht an
das Unblocking gebunden ist sondern schlicht per Cronjob ausgeführt
wird, könnte dies bedeuten, hat jemand mehr als 10 Angriffe in der
angegebenen Zeitspanne von BFB_WEBSERVER_LOGFILE_CLEAR= wird er immer
nur die neuesten 10 sehen können. Oder verstehe ich das falsch?

Ich halte die "alte" Variante für besser, in der die *.html Dateien
gelöscht werden, die nicht mehr geblockt sind. Ein "archivieren" von
Angriffen um diese später noch zu diagnostizieren könnte ja immer noch
als Zusatzoption gegeben sein.

So, und aus aktuellem Anlass noch einen Punkt den ich heute erst beim
Testen gefunden habe und der zu den "verstümmelten" Dateinamen passt.
Ich habe mich zu Testzwecken heute selber angegriffen und bekam von BFB
eine Mail in der mir gesagt wurde, dass ich die Details unter folgender
Adresse finde.
http://eisfair.home.lan/brute_force_blocking/p2e568238.dip0.t-ipconnect.de.html

Das ist schon komisch, denn normalerweise ist die *.html Datei immer die
IP und nicht der DNS Name. Die dazugehörige Datei die auf meinem Eisfair
liegt ist auch eine 46.86.130.56.html womit schon mal der Link in der
Mail nicht stimmt. Es kommt aber noch wilder. BFB hat einen Angriff der
einige Zeit vorher kam und meinen Angriff zusammengewürfelt.
Im access-Log findet man es so:

181.49.113.62 - - [21/Jan/2017:12:21:50 +0100] "GET
/phpMyAdmin/scripts/setup.php HTTP/1.1" 404 6484 "-" "-" 66 6739
181.49.113.62 - - [21/Jan/2017:12:21:51 +0100] "GET
/pma/scripts/setup.php HTTP/1.1" 404 6484 "-" "-" 59 6739
181.49.113.62 - - [21/Jan/2017:12:21:51 +0100] "GET
/myadmin/scripts/setup.php HTTP/1.1" 404 6484 "-" "-" 63 6739
p2e568238.dip0.t-ipconnect.de - - [21/Jan/2017:12:23:10 +0100] "GET
/test.html HTTP/1.1" 404 6484 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64;
Trident/7.0; rv:11.0) like Gecko" 271 6795
p2e568238.dip0.t-ipconnect.de - - [21/Jan/2017:12:23:12 +0100] "GET
/test.html HTTP/1.1" 404 6484 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64;
Trident/7.0; rv:11.0) like Gecko" 271 6795
p2e568238.dip0.t-ipconnect.de - - [21/Jan/2017:12:23:12 +0100] "GET
/test.html HTTP/1.1" 404 6484 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64;
Trident/7.0; rv:11.0) like Gecko" 271 6795

es liegen als ca. 1:20 min zwischen den beiden Angriffen von
unterschiedlichen IPs.
In der 46.86.130.56.html, welches meine derzeitige IP ist steht folgendes.

APACHE on schabau.goip.de was attacked

#################################################################
181.49.113.62 - - [21/Jan/2017:12:21:50 +0100] "GET
/phpMyAdmin/scripts/setup.php HTTP/1.1" 404 6484 "-" "-" 66 6739
181.49.113.62 - - [21/Jan/2017:12:21:51 +0100] "GET
/pma/scripts/setup.php HTTP/1.1" 404 6484 "-" "-" 59 6739
181.49.113.62 - - [21/Jan/2017:12:21:51 +0100] "GET
/myadmin/scripts/setup.php HTTP/1.1" 404 6484 "-" "-" 63 6739
#################################################################
Use of the encoding pragma is deprecated at /usr/bin/gwhois line 80.
Process query: 'p2e568238.dip0.t-ipconnect.de'
Querying whois.denic.de:43 with whois.

Domain: p2e568238.dip0.t-ipconnect.de
Status: invalid

-- 
To resolve one of the above handles: whois -h whois.denic.de HANDLE
OTOH offical handles should be recognised directly.
Please report errors or misfits via the debian bug tracking system.
#################################################################
traceroute to p2e568238.dip0.t-ipconnect.de (46.86.130.56), 20 hops max,
60 byte packets
1 fritz.box (192.168.0.1) 0.340 ms
2 p2E568238.dip0.t-ipconnect.de (46.86.130.56) 1.494 ms !X

Im Debug-Log von BFB steht dazu:

...
sende Mail
Subject: brute force attack detected
To: root at home.lan
From: root at localhost
erzeuge insgesamt 1 mail mit foldenden Daten
Subject: brute force attack detected
To: root at home.lan
From: root at localhost
eisfair detected an attack from p2e568238.dip0.t-ipconnect.de to APACHE
Accesslistscan on 21.01.2017 12:23:15
schabau.goip.de wurde attakiert
see details on
http://eisfair.home.lan/brute_force_blocking/p2e568238.dip0.t-ipconnect.de.html
too

========================================================
Use of the encoding pragma is deprecated at /usr/bin/gwhois line 80.
Process query: 'p2e568238.dip0.t-ipconnect.de'
Querying whois.denic.de:43 with whois.

Domain: p2e568238.dip0.t-ipconnect.de
Status: invalid

-- 
  To resolve one of the above handles: whois -h whois.denic.de HANDLE
  OTOH offical handles should be recognised directly.
  Please report errors or misfits via the debian bug tracking system.

========================================================
traceroute to p2e568238.dip0.t-ipconnect.de (46.86.130.56), 20 hops max,
60 byte packets
 1  fritz.box (192.168.0.1)  0.326 ms
 2  p2E568238.dip0.t-ipconnect.de (46.86.130.56)  1.238 ms !X
createhtml_ipaddress=46.86.130.56
createhtml_root=/var/www/htdocs/brute_force_blocking
createhtml_dateiname=/var/www/htdocs/brute_force_blocking/46.86.130.56.html
ip=p2e568238.dip0.t-ipconnect.de
logfile=/var/www/log/schabau_error_log
vhostname1=schabau.goip.de
accesslogfile=/var/www/log/schabau_access_log
FQDN_ANGREIFER=181.49.113.62
...

Olaf, irgend was scheint bei BFB in letzter Zeit wirklich zu haken.

Viele Grüße
Detlef Paschke

-- 
registered Fli4l-User #00000209
Das "Zitat des Augenblicks" gibt es nur auf
http://www.schabau.goip.de