common configuration:
START_BRUTE_FORCE_BLOCKING='yes'
Hier wir festgelegt ob BFB beim Systemstart mitstarten soll.
BFB_LOGLEVEL='debug'
Hier kannst Du festlegen, mit welchem Level Meldungen im Messagelog gemeldet werden. Probiere es aus, was dir am besten liegt. Standat ist ‘debug’. Du kannst aber wählen zwischen debug|info|notice|warning|error|crit|alert|emerg
BFB_USE_RAMDISK='yes'
Wenn genügend RAM vorhanden ist, so kann eine RAM-Disk verwendet
werden. Diese legt BFB an. Der Vorteil die HD kann sich schlafen legen :-)
BFB_ATTACK_TIMES='6'
Nach wievielen fehlerhaften Loginversuchen soll BFB blocken? Nicht sinnvoll sind kleiner = 3.
BFB_BLOCK_TYPE='REJECT'
Sollen die IP-Adressen Rejected oder droped werden? Der Unterschied wird weiter unten erklärt.
BFB_UNBLOCK_TIME='1 1 * * *'
Die Uhrzeit, wo alle geblockten IP-Adressen wieder frei gegeben werden. Es ist nicht sinnvoll alle 10
Minuten oder so einzutragen.
BFB_RESTART_ON_UNBLOCK='no'
Bei einigen Usern hat BFB nach einem längerem Zeitraum eine hohe Systemlast verursacht. Die Ursache konnte nie gefunden werden. Sollte also bei Dir auch dieses Phänomän auftauchen, so musst Du hier 'yes' eintragen. Dadurch wird BFB zur UNBLOCK_TIME restartet.
BFB_RESOLVE_DNS='no'
Soll die IP-Adresse, welche einen Attacke gemacht hat per DNS aufgelöst werden?
Brute Force Blocking Monitor configuration:
BFB_MONITOR_MINI_HTTP='yes'
Soll der mini-http mit überwacht werden? Wenn vorhanden, dann sinnvoll.
BFB_MONITOR_FTPD='yes'
Soll auf fehlerhafte Logins per FTP gecheckt werden?
BFB_MONITOR_IMAP='yes'
Soll auf Versuche den IMAP-Server zu hacken geachtet werden?
BFB_MONITOR_SN='yes'
Wenn beim Newspacket Authentifizierung verlangt wird, kann hier gesagt werden, dass auch der
SN mit überwacht wird.
BFB_MONITOR_PORTSCAN='yes'
BFB versucht portscans zu detektieren. Dies wird gemacht indem Verbindungsaufbauten zu den unter BFB_PORTSCAN_RANGE_% angegebenen Ports geloggt werden. Sollten innerhalb von 10 Minuten mehr als bei BFB_ATTACK_TIMES eingetragen sein, so wird die IP-Adresse des Scanners geblockt.
BFB_MONITOR_BOT_ATTACK='yes'
Soll BFB SSH-BOT-Attacken mit überwachen? yes/no. Was sind SSH-BOT-Attacken?
Viele
BFB-ähnliche Programme scannen auch die Logfiles und sperren dann die angreifende IP. Das wissen auch professionelle "Cracker" und verwenden immer häufiger BOT-Netze. Das hat für diese Programme, dass pro IP-Adresse nur 1-2-Einträge in den Logfiles auftauchen. Also wird nichts geblockt. BFB zählt nun die gesammten fehlerhaften Loginversuche. Wenn mehr als unter BFB_MONITOR_BOT_ATTACK_ATTEMPTS eingestellten Loginversuche stattgefunden habe wird der komplette SSH-Port gesperrt, ausser
die -IP-Adressen, welche unter BFB_BOT_FREE_IP_ADDRESS_% konfiguriert wurden. Dadurch ist es dem Admin trotzdem noch möglich sich per SSH auf den Server einzuloggen. Nach 20 Minuten wird der SSH-Port wieder deblockt.
BFB_MONITOR_SLOW_ATTACK='yes'
Es ist eine Variable für langsame BOT-Attacken hinzugekommen. Ich
habe auf einigen meiner eisfair festgestellt, dass die SLOW-BOT-ATTACKEN
immer häufiger werden.
Was sind SLOW-BOT-ATTACKEN?
Von einer IP-Adresse wird ein Loginversuch unternommen. Wenn der
scheitert wird der nächste Versuch erst nach einigen Stunden
unternommen. In dieser Zeit wird von einer anderen IP nach ca 20-30
Minuten unternommen. Wenn der Versuch nicht erfolgreich ist, kommt nach
langer Zeit die nächste IP dran u.s.w.
So ist im auth-log ca alle 20 Minuten ein login von irgendeiner IP zu
sehen, die sich aber nur alle paar Stunden wiederholt. Soweit ich weis
gibt es bisher kein Programm, welches so eine Attacke erkennt (z.B.
fail2ban).
Diese Variable ist nur sichtbar, wenn BFB_MONITOR_SLOW_ATTACK='yes' eingestellt wurde.
BFB_MONITOR_SPECIFIC_PORT='yes' Wenn u.g Ports via ipt_recent überwacht werden sollen, dann bitte 'yes' eintragen.
BFB_MONITOR_BREAKIN_ATTEMPT='yes'
Viele 'Cracker' versuchen mit gespooften IP-Adressen sich einzuloggen. Das erkennt der sshserver und BFB blockt
dann sogleich die IP-Adresse
BFB_MONITOR_CACTI='yes'
Wenn Du Cacti installiert hast, kann BFB das Webinterface auf unauthorisierte Loginversuche überwachen. Dazu musst Du nur unter BFB_CACTI_SERVER_IP_ADDRESS die IP-Adresse eintragen, auf der dec CACTI-Server läuft. 127.0.0.1 sollte aber vermieden werden, sondern die IP-Adresse eingetragen werden, welche der Server selbst hat (eth0 oder eth1). BFB kann zwar auch entfernet CACTI-Server überwachen, dort aber noch nicht blocken.
BFB_MONITOR_WEBACCESS='yes'
Soll der Webserver auf Hackversuchen kontrolliert werden?
BFB_MONITOR_SMBWEBCLIENT='yes'
Wenn der SMBwebclient verwendet wird, dann kann dieser auch überwacht werden.
BFB_MONITOR_TELNET='no'
Bei Telnet ist darauf zu achten, dass im Logfile immer die aufgelösten
IP-Adressen geloggt werden. Deshalb wird aus dieser Resolveadresse
mittels DIG die IP-Adresse gewonnen. Das heisst aber auch, dass
IP-Adressen ohne Reverseeintrag evtl. nicht erkannt werden. Attacken aus
dem eigenen LAN definitiv nicht. Aber Telnet sollte ja eh nicht
verwendet werden. :-)
BFB_MONITOR_ADDITIONAL_LOG='no'
Wenn Du andere Dienste auf dem Server in Betrieb hast, die von Internet aus erreichbar sind, kannst Du hiermit die Logfiles mit überwachen lassen. Dazu musst Du aber ein eigenes Script schreiben. In diesem Script kannst Du natürlich auch mehrere Logfiles überwachen lassen und BFB
blockt dann bei Bedarf die angreifende IP-Adresse.
free ip address configuration:
BFB_FREE_IP='192.168.11.13 127.0.0.1'
IP-Adressen, welche nie geblockt werden sollen. Hier ist es sinnvoll die localen IP-Adressen einzugeben.
BFB_FREE_IP_GROUP='192.168.10.2-192.168.10.55'
Wenn man mehrere IP-Adressen hat, die in einer Range liegen, so kann diese hier eingegeben werden. Diese Range wird dann auch nie geblockt. Es ist nur eine Range zulässig.
BFB_FREE_LAN_DOMAIN='router.home.lan'
Hier kannst Du eine aufgelöste Adresse eingeben, welcher Rechner immer Zugriff auf Server haben soll. Dieser Eintrag ist dem FTPD geschuldet, welcher die IP-Adresse evtl auflöst und bei fehlerhaften Logins die aufgelöste IP-Adresse nicht unter BFB_FREE_IP findet und blockt.
BOT-Attack configuration:
BFB_MONITOR_BOT_ATTACK_ATTEMPTS='30'
Hier die Anzahl der maximal fehlerhaften Loginversuche eintragen, bevor BFB den
kompletten SSH-Port blockt. Dieser Wert sollte nicht zu niedrig sein um Fehlalarme zu vermeiden. In der Praxis hat sich die Zahl 30 als praktikabel erwiesen.
BFB_BOT_FREE_IP_NET='192.168.10.0/24'
Dieser IP-Bereich wird bei einer BOT-Attacke nicht geblockt. Dadurch kann man z.Bsp. vom LAN auch bei geblocktem SSH-Port sich auf dem Server einloggen.
BFB_BOT_FREE_IP_ADDRESS_N='5'
Anzahl weiterer Adressen, welche sich trotz geblocktem SSH-Port auf dem Server
einloggen können.
BFB_BOT_FREE_IP_ADDRESS_%='1.2.3.4'
IP-Adresse, welche bei einer BOT-Attacke nicht geblockt wird. Dadurch kann man sich von dieser Adresse auch bei geblocktem SSH-Port auf dem Server einloggen.
logfile configuration
BFB_EXTENDED_LOG_TO_MESSAGELOG='no'
Hier yes eintragen, wenn gewünscht wird, dass nach der Sperrung weitere Versuche dieser IP im messagelog mitgeloggt erden sollen.
BFB_USE_OWN_FTPD_LOGFILES='no'
Einige
User verwenden zum loggen für den FTPD nicht die /var/log/messages. Deshalb kann man hier angeben, ob der FTPD in ein eigenes Logfiles schreibt.
BFB_FTPD_LOGFILE='ftpdlogfile'
Wenn bei BFB_USE_OWN_FTPD_LOGFILES yes eingetragen wurde und der PureFTPD ein eigenes Logfile verwenden, dann dieses bitte hier eintragen.
BFB_USE_OWN_IMAP_LOGFILES='no'
Einige User verwenden zum loggen für den IMAPD/EXIM/VMAIL nicht die /var/log/messages. Deshalb kann man hier
angeben, ob der Maildienst in ein eigenes Logfiles schreibt.
BFB_IMAP_LOGFILE='maillogfile'
Wenn bei BFB_USE_OWN_IMAP_LOGFILES yes eingetragen wurde und der IMAPD bzw VMAILD ein eigenes Logfile verwenden, dann dieses bitte hier eintragen.
BFB_USE_OWN_SN_LOGFILES='no'
Einige User verwenden zum loggen des SN-Newsservers nicht die /var/log/messages. Deshalb kann man hier angeben, ob der SN in ein eigenes Logfiles schreibt.
BFB_SN_LOGFILE='snlogfile'
Wenn bei BFB_USE_OWN_SN_LOGFILES yes eingetragen wurde und der SN ein eigenes Logfile verwenden, dann dieses bitte hier eintragen.
BFB_USE_OWN_AUTH_LOGFILES='no'
Einige User verwenden zum loggen des SSH-servers nicht die /var/log/messages. Deshalb kann man hier angeben, ob der SN in ein eigenes Logfiles schreibt.
BFB_AUTH_LOGFILE='authlogfile'
Wenn bei BFB_USE_OWN_AUTH_LOGFILES yes eingetragen wurde und der SSH-Server
ein eigenes Logfile verwenden, dann dieses bitte hier eintragen.
BFB_USE_OWN_SMBWEB_LOGFILES='no'
Einige User verwenden zum loggen des smbwebclient nicht die /var/log/messages. Deshalb kann man hier angeben, ob der smbwebclient in ein eigenes Logfiles schreibt.
BFB_SMBWEBCLIENT_LOGFILE='smbwebclientlogfile'
Wenn bei BFB_USE_OWN_SMBWEB_LOGFILES yes eingetragen wurde und der smbwebclient ein eigenes Logfile verwenden, dann dieses bitte hier eintragen.
BFB_USE_OWN_KERNEL_LOGFILES='no'
Einige User verwenden zum loggen der Kernelmessages nicht die /var/log/messages. Deshalb kann man hier angeben, ob die kernelmessages in ein eigenes Logfiles schreiben.
BFB_KERNEL_LOGFILE='kernellogfile'
Wenn bei BFB_USE_OWN_KERNEL_LOGFILES yes eingetragen wurde und die kernelmessages ein eigenes Logfile verwenden, dann dieses bitte hier eintragen. Das ist wichtig für die Portscans.
portscan configuration:
BFB_PORTSCAN_RANGES_N='5'
Anzahl der Portranges, welche für die Überwachung auf Portscans genutzt werden können.
BFB_PORTSCAN_RANGE_%='89:100'
Hier kannst Du die Ports eintragen, welche nicht von einem eigenen Dienst genutzt wird, aber bei Portscans mit gescannt werden. Die Defaultwerte haben sich in der Praxis bewährt.
BFB_PORTSCAN_LOGLEVEL='debug'
Hiermit erkennt BFB mit welcher Priorität BFB die Meldungen zum Portscan in das Kerlenlog
schreibt. Ist nur nötig, wenn Du ein Service verwendest, der die Logfiles auswertet (z.B php-syslgo-ng). Wenn Du 'critical' einträgst werden die Meldungen auch auf der Konsole angezeigt.
specifi port configuration:
BFB_SPECIFIC_PORTS_N='1'
Hier bitte die Anzahl der speziellen Ports eintragen (BFB_MONITOR_SPECIFIC_PORT)
BFB_SPECIFIC_%_PORTS
Hier kannst Du die Ports eintragen, bei denen sofort mit ip_recent die IP-Adresse geblockt wird.
BFB_EXTERNAL_INTERFACE='eth0'
Bitte hier das Interface eintragen, wo der ausgehende Traffic geroutet wird. Ist nötig für ip_recent (BFB_MONITOR_SPECIFIC_PORT)
syslog-server configuration:
BFB_SERVER_RUN_AS_SYSLOGSERVER
Wenn der EIS als Syslogserver fungiert, dann hier bitte yes eintragen.
BFB_SERVER_SYSLOGSERVER_HOSTNAME
Hier bitte den eigenen Servernamen eintragen, welcher in den Logfiles auftaucht.
Dieser Eintrag wird dazu genutzt um BFB nur die
Messages auswerten zu lassen, welche von dem eigenen Server stammen. Damit werden Fehlalarme vermieden, welche durch Messages hervorgerufen werden würden, die von externen Servern stammen.
webserver configuration:
BFB_REQUEST_BLOCKS_VIA_WEBSERVER='yes'
Sollen die Attacken im Webbrowser aufgelistet werden?
BFB_USE_APACHE_VERSION='2'
Welche Apacheversion wird versendet? 1 oder 2?
BFB_APACHE_DOCUMENTROOT='/var/www/htdocs'
Wo befindet sich sich der Ordnr des Apache?
BFB_HTML_INDEX_FOLDER='brute_force_blocking'
Hier bitte den Ordner eintragen unter dem Du im Webbrowser die Auswertung anschauen willst.
in Beispielfall wäre es hier jetzt
http://Deine.ip.de/brute_force_blocking
BFB_CGI_BIN_DOCUMENTROOT='/var/www/cgi-bin'
... und der cgi-Ordner?
BFB_HTML_REFRESH_PATH='./cgi-bin/brute_force_blocking.cgi'
der Pfad, wo das cgi-File liegt, inklusive des cgi-files
BFB_OWN_WEBDOMAIN_NAME='http://dein.server.de'
Der Domainname, von wo aus dein Server vom Internet aus erreichbar ist, also deine evtuelle dyndns-domain.
BFB_SHOW_ATTACK_DETAILS_ON_WEB='yes'
Wenn Du die Logeintrag, sowie den Traceroute und die Whois-Abfrage im Webbrowser sehen willst, dann hier bitte 'yes' eintragen
BFB_WEBSERVER_LOGFILE_CLEAR='1 1 * * 6'
Hier wird
angegeben, wann das Logfile gelöscht wird, welches über einen Webbrowser einzusehen ist?
additional logfile configuration:
BFB_ADDITIONAL_LOG_SCRIPT='/dein/eigenes/bfb-script'
Der Pfad zu deinem eigenen BFB-script, welches Du im Zuge von BFB_MONITOR_ADDITIONAL_LOG erstellt hast.
Information configuration:
BFB_SEND_MAIL='yes'
Möchtest Du über jeden Angriff per Mail informiert werden?
BFB_MAIL_TO_ADDRESS='root@foo.bar'
Wenn ja, an welche Mail-adresse soll diese Mail geschickt werden?
BFB_MAIL_FROM_ADDRESS='root@foo.bar'
Die Email-Adresse, welche als Absender stehen soll. Dabei kannst Du Namen (ohne Leerzeichen) oder die korrekte Email-Adresse angeben. (bis Version 0.3.5 als Name nur ‘root’)
BFB_MAIL_SUBJECT='[Brute Force] attack detected!'
... und welchen Betreff möchtest Du haben?
BFB_MAIL_WITH_WHOIS_REQUEST='yes'
Möchtest Du eine Whois-Abfrage per Mail zugeschickt bekommen? Wenn ja, kann man damit den Eigentümer des Angreifenden Servers erfahren. Wenn es allerdings eine Dial-In Adresse ist, hat man kaum Chancen. Eine Dial-In Adresse erkennt man meisstens daran, dass Dial-In in der aufgelösten Adresse drin steht
z.bsp.: dip.t-dialin.net
BFB_MAIL_WITH_TRACEROUTE_REQUEST='yes'
Hier gilt eigentlich das selbe wie für die Whois-Abfrage,
nur dass hier ein Traceroute gemacht wird.
BFB_ALL_INFO_IN_SAME_MAIL='yes' die o.g. Abfragen werden in eine eMail gepackt. Ansonsten kommt für jede Abfrage eine seperate Mail.
BFB_WRITE_ATTACK_TO_TXTFILE='no' Speichert alle verfügbaren Daten (traceroute, whois, Logauszug) in einem Textfile
BFB_ATTACK_TXTFILE_FILENAME='/pfad/zum/file'
Der Pfad zu dem o.g Testfile.
BFB_ATTACK_FILE_CLEAR_CRON='1 0 1 * *'
Zu diesem Zeitpunkt wird o.g Textfile geleert.
BFB_SEND_VIA_CURL='no'
Soll BFB Meldungen zu einem via Curl erreichbaren externen Dienst schicken?
nicht Twitter!!
Curl configuration:
BFB_CURL_USERNAME='username'
Der Accountname/Username des extenen Dienstes
BFB_CURL_PASSWORD='Passwort'
Das Passwort des extenen Dienstes
BFB_CURL_TEXT='BFB-attack detected from'
Der Text, welcher dann beim exterem Dienst auftaucht.
Die IP-Adresse fügt BFB automatisch hinzu.
BFB_CURL_ADDRESS='http://die URL für das update'
Die Adresse, an die die Meldung geschickt wird.
Twitter Konfiguration:
BFB_SEND_TO_TWITTER='yes'
Wenn Du die BFB-Meldungen über Sperrungen bei Twitter veröffentlichen willst.
BFB_TWITTER_USERNAME='username'
Dein Twitter username. Bitte beachte unten die Anleitung für die Erzeugung des O-Auth-files!
BFB_TWITTER_TEXT='BFB-attack detected from'
Der Text, welcher dann bei Twitter auftaucht. Die IP-Adresse fügt BFB automatisch hinzu.
Cacti configuration:
BFB_CACTI_SERVER_IP_ADDRESS='192.168.10.3'
Hier die IP-Adresse eintragen, auf der dec CACTI-Server läuft. 127.0.0.1 sollte aber vermieden werden, sondern die IP-Adresse eingetragen werden, welche der Server selbst hat (eth0 oder eth1). BFB kann zwar auch entfernet CACTI-Server überwachen, dort aber
noch nicht blocken.
BFB_BLOCK_PROACTIVE_FROM_ATMA='yes'
BFB kann von 2 Twitteraccounts IP Adressen downloaden, die dann proaktiv gesperrt werden. Von diesen IP Adressen wurden zuvor auf verschiedene Systeme Hack versuche gestartet. Sie sind vermutlich verseucht oder gehackt. BFB blockt deshalb diese Adressen schon vorher.
BFB_BLOCK_PROACTIVE_CRON='22 * * * *'
Wie oft soll die Liste mit den verseuchten IP Adressen aktualisiert werden?
Mit diesem Cronjob werden nur neue Adressen hinzugefügt, aber keine geblockten entblockt. Das geschieht weiterhin über die unblock-funktion.
BFB_MONITOR_ASTERISK='yes'
Soll das Asterisk-Logfile auf Hackversuche überwachte werden. Damit sind versuche gemein, welche darauf abzielen den Asterisk für kostenlose Gespräche zu hacken.
BFB_ASTERISK_ATTEMPT_NUMBER='4'
Gib bitte die Anzahl an, wie oft ein fehlerhafter Login erlaubt ist. Default ist 4 (Es kann ja
wirklich mal sein, dass man selber was falsch gemacht hat :-)
BFB_USE_OWN_ASTERISK_LOGFILE='no'
Einige User verwenden zum loggen der Asteriskmessages nicht /var/log/asterisk/message. Deshalb kann man hier angeben, ob der Asterisk die messages in ein eigenes Logfiles schreiben
BFB_ASTERISK_LOGFILE='/var/log/asterisk/messages'
der komplette Pfad zum Asterisk-Logfile
BFB_CHECK_NEW_VERSION='yes'
Da sich in letzter Zeit die Anfragen
gehäuft haben, warum das BFB-Paket nicht unter ''Upgradable packages'' aufgezählt wird, habe ich mich entschlossen eine Funktion einzubauen, welche es ermöglicht auf eine Neue BFB-Version zu prüfen. Wenn also hier ‘yes’ eingetragen wird, so prüft ein Cronjob regelmäßig, ob es eine neuen BDB-Version gibt und informiert dann den Admin per Mail.
BFB_CHECK_NEW_VERSION_CRON='22 21 * * *'
Wann soll BFB nach einer neuen Version suchen?
BFB_CHECK_NEW_VERSION_TO_ADDRESS='root'
Wer soll informiert werden (Email-Adresse)?
BFB_CHECK_NEW_VERSION_FROM_ADDRESS='root'
Wer soll als Absender bei den Mails auftauchen? Dabei kannst Du Namen (ohne Leerzeichen) oder die korrekte Email-Adresse angeben. (bis Version 0.3.5 als Name nur ‘root’)