| common configuration:
START_BRUTE_FORCE_BLOCKING='yes'
Hier wir festgelegt ob BFB beim Systemstart mitstarten soll.
BFB_WAITTIME='10'
Hier kann man die Wartezeit einstellen, die BFB einhält bevor es die Logfiles erneut durchsucht. Nach Möglichkeit sollte 10 stehenbleiben. Nur auf Systemen, bei denen BFB eine sehr hohe CPU-Last erzeugt, kann man hier 15 oder 20 eingeben.
BFB_BLOCK_REMOTE_SERVER='no'
Wenn ihr vor dem EIS eine Firewall habt, an der auch noch andere Server hängen, die auch alle geschützt werden
sollen, kann es sinnvoll sein die attakierenden IP-Adressen schon auf dieser Firewall zu blocken. Dafür ist diese Variable gedacht. Wenn hier 'yes' eingetragen wird, werden die attakierenden IP-Adressen nur noch auf dem Remoteserver/Firewall geblockt. Sinnvoll ist diese Funktion vorallem wenn
BFB_SERVER_RUN_AS_SYSLOGSERVER='yes'
steht, der EIS also als Syslogserver fungiert. Ansonsten ''sieht'' der EIS ja die Loginversuche auf den anderen
Maschinen nicht. Natürlich geht es auch in der Konstellation, dass nur der EIS alle Server hostet und trotzdem auf der vorgeschalteten Firewall geblockt werden soll.
Getestet wurde diese Funktion mit dem Fli4l und der IPCop-Firewall. Es sollte aber auch ohne Probleme auf jeder linuxbasierten Firewall gehen, die ssh-login unterstützt.
BFB_LOGLEVEL='debug'
Hier kannst Du festlegen, mit welchem Level Meldungen im Messagelog gemeldet werden. Probiere es aus, was dir am besten
liegt. Standard 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 hier 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?
Ein 'yes' verlangsamt aber BFB, da die IP-Adressen immer erst aufgelöst werden.
BFB_CHECK_FOR_NEW_VERSION='yes'
BFB checkt selbstständig ob es eine neue Version von BFB gibt.
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 BFB-Version gibt und informiert dann den Admin per Mail. Dabei wird nur die lokal installierte Version mit der Version auf dem Webserver verglichen. Es werden keine persönlichen Daten übertragen
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_MAIL='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 den Vorteil, 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.
ACHTUNG: Diese Funktion ist noch nicht getestet, wenn der EIS auf einem Remoteserver blockt!!
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 die Attacke von anderen IP's weitergeführt und die anderen erst nach ca 20-30 Minuten genommen.
So ist im auth-log nur 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.
Diese Funktion ist nur verfügbar, wenn nicht auf einer vorgeschalteten Firewall geblockt wird.
BFB_MONITOR_BREAKIN_ATTEMPT='yes'
Viele 'Cracker' versuchen mit gespooften IP-Adressen sich einzuloggen. Das erkennt der SSH-server 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 der 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 nicht blocken.
BFB_MONITOR_WEBACCESS='yes'
Soll der Webserver auf Hackversuche 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_ASTERISK='yes'
Soll das Asterisk-Logfile auf Hackversuche überwachte werden? Damit sind
Versuche gemeint, welche darauf abzielen den Asterisk für kostenlose Gespräche zu hacken.
BFB_ASTERISK_ATTEMPT_NUMBER='4'
Gib hier 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_MONITOR_ADDITIONAL_LOG='no'
Wenn Du andere Dienste auf dem Server in Betrieb hast, die vom 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_N='1'
Wenn man ganze Gruppen von IP-Adressen hat, welche nie
geblockt werden sollen, so kann man hier bestimmen wieviel Gruppen man freischalten möchte.
BFB_FREE_IP_GROUP_%='192.168.10.2-192.168.10.55'
Hier die x.Range eintragen, welchen nie geblockt werden soll.
BFB_FREE_LAN_DOMAIN='router.home.lan'
Hier kannst Du eine aufgelöste Adresse eingeben, welcher Rechner immer Zugriff auf den 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 deshalb 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 sich, z.Bsp. vom LAN aus, 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='/var/log/messages'
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_MAIL_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_MAIL_LOGFILE='/var/log/messages'
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='/var/log/messages'
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='/var/log/messages'
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='/var/log/messages'
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='/var/log/messages'
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.
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
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 deinen eigenen Diensten genutzt werden, 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='135'
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_MONITOR_ONLY_LOCAL_SERVER='yes'
Wenn der EIS als Syslogserver läuft, kann es Sinn machen ihn nur die eigenen Einträge monitoren zu lassen. Gerade wenn der EIS nicht für alle Server, welche in das Logfile schreiben, die Attacken überwachen soll, weil sich die anderen Server in anderen Lokationen/an anderen Orten befinden. Wenn der EIS also nur sich selber überwachen soll, dann hier bitte
'yes' auswählen.
BFB_SERVER_SYSLOGSERVER_HOSTNAME='EIS'
Wenn BFB_MONITOR_ONLY_LOCAL_SERVER='yes' ist, dann bitte hier den eigenen Servernamen eintragen, welcher in den Logfiles auftaucht.
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'
In welchen Ordner des Apache soll die Auflistung stattfinden? Standardmäßig ist hier das Dokumentenroot des Apacheservers einzutragen. Wenn man aber VHOSTS nutzt kann man auch einen anderen Ordner eintragen. In diesen Ordner wird dann ein neuer Ordner erstellt, in dem dann die Angriffe protokoliert werden. (siehe nächste Variable)
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? Bei Verwendung von VHOSTS muss es im selben Stammordner liegen.
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-Adresse.
BFB_SHOW_ATTACK_DETAILS_ON_WEB='yes'
Wenn Du die Logeinträge, 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.
Proactive configuration:
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 (proaktiv). BFB_BLOCK_PROACTIVE_CRON='22 * * * *'
Wie oft soll die Liste mit den verseuchten IP Adressen aktualisiert werden?
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!!
BFB_SEND_TO_TWITTER='yes'
Wenn Du die BFB-Meldungen über Sperrungen bei Twitter veröffentlichen willst.
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_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 der 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 nicht blocken.
Check new Version configuration:
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’)
Remote blocking configuration:
BFB_BLOCK_REMOTE_SERVER_IP='192.168.10.6'
Hier die IP-Adresse deiner Firewall eintragen, auf der die IP-Adressen geblockt werden sollen.
BFB_BLOCK_REMOTE_SERVER_PORT='22'
Hier muss der SSH-Port eingetragen werden, über den auf die Firewall zugegriffen werden kann.
BFB_BLOCK_REMOTE_FORWARD_CHAIN='PORTFWACCESS'
Hier muss die iptables Chain eingetragen werden, in der festgelegt
wird, wohin welche Ports weitergeleitet werden. Standardmäßig ist das die Chain PORTFWACCESS.
Überprüfen kann man das indem man sich auf die Firewall einloggt und
iptables -nL
eingibt. Es sollte nun eine lange Liste erscheinen. Irgendwo dort müssen die Weiterleitungen definiert sein.
Das könnte wie folgt aussehen:
Chain PORTFWACCESS (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 192.168.0.2 tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 192.168.0.2 tcp dpt:80
oder so:
Chain PORTFWACCESS (2 references)
target prot opt source destination
ACCEPT
tcp -- 0.0.0.0/0 192.168.0.5 tcp dpt:22 /* prot:tcp any 192.168.2.2:22 DNAT:192.168.1.5:22 */
Ansonsten müsst ihr die Chain hier eintragen, wo ihr so einen Eintrag findet.
BFB_BLOCK_REMOTE_SERVER_USE_OWN_COMMAND='no'
Wenn ihr für das Blocken der IP’s auf eure Firewall ein eigenes Script verwenden wollt, so könnt ihr hier ein 'yes' eintragen. Wichtig ist nur das als 1. Variable die
IP-Adresse und als 2. Variable start oder stop übergeben werden kann.
BFB_BLOCK_REMOTE_SERVER_OWN_COMMAND='Dein/eigenes/Script'
Selbsterklärend, oder?
BFB_BLOCK_REMOTE_SERVER_USER='root'
der User, als den sich BFB bei der Firewall einloggt. Dieser User sollte die Rechte haben iptables auszuführen.
BFB_BLOCK_REMOTE_SERVER_PASSWD='geheim'
Das Password des o.g. Users. Dieses Feld kann leer bleiben, wenn ein putty-sshkey verwendet wird, bei
dem kein Passwort erforderlich ist. (Siehe nächste Variable)
BFB_BLOCK_REMOTE_SSH_KEY='/Pfad/zu/deiner/firewall.ppk'
Wenn ein Keyfile benötigt wird oder verwendet werden soll, so ist hier der Pfad anzugeben. Wichtig ist, dass er mit puttygen erstellt wurde.
| |