phpmyadmin mit fail2ban absichern
seit phpmyadmin 4.8 gibt es endlich eine logging funktion fuer die fehlgeschlagenen logins. diese kann man dann wunderbar per fail2ban auswerten. frueher war das eher eine wurschtelei mit customized apache logs oder gar aenderungen an den installierten phpmyadmin dateien (welche nach einem update wieder futsch waren). standardmaessig ist diese logging funktion auch enabled und schreibt die fehlgeschlagenen logins ins php error logfile oder syslog. der parameter in der config.inc.php heisst $cfg[‘AuthLog’] und hat den wert “auto”. phpmyadmin entscheidet dann selbststaendig, ob es ins php error log oder syslog schreibt. in meinem falle machte es das ins php error log. wenn nicht, kann man den wert entsprechend setzen.
hier ist das die datei /var/www/webxxxx/logs/priv/php_errors.log. die eintraege im log haben dieses format:
[19-May-2019 21:07:49 Europe/Berlin] user denied: phpmyadmin (mysql-denied) from 46.246.65.167 |
zuerst muss man einen entsprechenden filter fuer fail2ban konfigurieren. dazu einfach die datei /etc/fail2ban/filter.d/phpmyadmin.conf mit diesem inhalt anlegen:
[Definition] denied = mysql-denied|allow-denied|root-denied|empty-denied failregex = ^.*(%(denied)s).* from <HOST>$ ignoreregex = |
beim debuggen seiner eigenen regex kann die seite debuggex.com sehr hilfreich sein. testen kann man seinen selbst erstellten filter mit diesem befehl:
fail2ban-regex /var/www/webxxxx/logs/priv/php_errors.log /etc/fail2ban/filter.d/phpmyadmin.conf |
im ergebnis sollten dann irgendwie so in der art aussehen:
[...] Lines: 31 lines, 0 ignored, 10 matched, 21 missed [...] |
bei “matched” sollte eine entsprechende anzahl groesser 0 auftauchen. wenn dem so ist, braucht man noch eine “jail” konfiguration fuer phpmyadmin. dazu die datei
/etc/fail2ban/jail.d/phpmyadmin.conf mit diesem inhalt anlegen:
[phpmyadmin] enabled = true port = http,https filter = phpmyadmin logpath = /var/www/webxxxx/logs/priv/php_errors.log |
einmal neu laden ….
service fail2ban reload |
… und einfach mal ein paar fehlerhafte loginversuche ausloesen. im php error log sieht das so aus:
[24-May-2019 07:51:45 Europe/Berlin] user denied: dasdsadsadas (empty-denied) from 87.xxx.xx.xx [24-May-2019 07:51:46 Europe/Berlin] user denied: dasdsadsadas (empty-denied) from 87.xxx.xx.xx [24-May-2019 07:51:47 Europe/Berlin] user denied: dasdsadsadas (empty-denied) from 87.xxx.xx.xx [24-May-2019 07:51:48 Europe/Berlin] user denied: dasdsadsadas (empty-denied) from 87.xxx.xx.xx [24-May-2019 07:51:49 Europe/Berlin] user denied: dasdsadsadas (empty-denied) from 87.xxx.xx.xx |
und korrespondierend im fail2ban logfile:
/var/log/fail2ban.log
2019-05-24 07:51:45,862 fail2ban.filter [1144]: INFO [phpmyadmin] Found 87.xxx.xx.xx 2019-05-24 07:51:46,936 fail2ban.filter [1144]: INFO [phpmyadmin] Found 87.xxx.xx.xx 2019-05-24 07:51:47,952 fail2ban.filter [1144]: INFO [phpmyadmin] Found 87.xxx.xx.xx 2019-05-24 07:51:48,832 fail2ban.filter [1144]: INFO [phpmyadmin] Found 87.xxx.xx.xx 2019-05-24 07:51:49,592 fail2ban.filter [1144]: INFO [phpmyadmin] Found 87.xxx.xx.xx 2019-05-24 07:51:50,303 fail2ban.actions [1144]: NOTICE [phpmyadmin] Ban 87.xxx.xx.xx 2019-05-24 08:01:51,276 fail2ban.actions [1144]: NOTICE [phpmyadmin] Unban 87.xxx.xx.xx |
bei dem jail greifen hier die fail2ban standard werte einer debian 9 installation. nach 5 fehlerhaften logins von einer IP wird diese fuer 10 minuten per iptables geblockt.
that’s it.
freenas, btx halted, asus P10S-I
…grad ein freenas 11.2 installiert mit dem motherboard asus P10S-I, kam das:
ich war halt per ipmi auf der kiste drauf und da macht “remote media” halt usb devices. und da scheints geklemmt zu haben. abhilfe brachte diese bios einstellung:
parkometer
ah ja… diesen begriff hab ich noch nie gehoert. gibts aber immerhin im deutschen duden. soll eine parkuhr sein… haette ich jetzt auch nicht als solche erkannt. haette eher auf einen briefkasten getippt.
wurst mit 25% gemueseanteil
fuer die leute, die weniger fleisch essen wollen oder wie?
da kann man dann ruhigen gewissens ne scheibe mehr aufs brot legen… denn gemuese ist gesund 😉
nachbar mull tone, hausnummer alte papier
ich dachte immer, das waeren fakes, wenn man sowas mal auf facebook oder twitter gesehen hat… bis man es dann selbst erlebt.
kein urinal! part 2
den hier hatte ich letztes jahr schon gepostet:
nun habe ich ein aehnliches modell eines anderen herstellers gesehen…
und das koennte echt zu verwechslungen fuehren! 😉
pi-hole “high availability” bzw. failover
gegen geschwaetzige geraete in meinem boesen multimedia vlan und nervige werbung im allgemeinen nutze ich pi-hole. das ist zwar kein allheilmittel, aber sorgt schonmal fuer eine solide basis im kampf gegen nerver und datensammler. fuer das finetuning kann man in pi-hole seine eigenen black- und whitelists pflegen. obendrein bietet die schicke weboberflaeche einiges an moeglichkeiten zur auswertung und administration.
im eigenen heimnetz bin ich gerne um ausfallsicherheit bemueht. an einigen stellen habe ich dafuer sorge getragen, an anderen muss ich noch etwas schrauben. unter anderem an der dns aufloesung ueber den pi-hole. wenn der mal aus irgendwelchen gruenden nicht will, hat man gleich kein funktionierendes netz mehr (also netz schon, aber ohne namensaufloesung wirds doof.)
abhilfe schafft man natuerlich mit einem zweiten pi-hole. dazu muesste man seinen geraeten zwei dns server bekannt machen. entweder per konfiguration im dhcp server oder bei geraeten mit fest eingetellter IP einen zweiten dns server eintragen. nun gibt es dhcp server implementierungen in irgendwelchen plaste routern, die nur das setzen eines dns servers erlauben. genauso habe ich geraete im hardware zoo, denen man nur einen dns server in der statischen netzwerk konfiguration eintragen kann.
selbst wenn diese beiden probleme nicht hat und zwei pi-hole’s gleichzeitig betreibt, bleiben unzulaenglichkeiten bei der administration. zum einen muss man die konfiguration auf beiden gleich halten, was man mit einem cronjob und rsync oder scp hin bekommt. zum anderen verteilen sich natuerlich auch die dns anfragen der clients auf zwei pi-holes, was dann die schicken statistik bildchen und auswertungen unbrauchbar macht.
auf der suche nach einer loesung bin ich auf einen artikel auf adminforge.de gestossen. da ist beschrieben, wie man unter linux mit “keepalived” eine art hochverfuegbarkeit mit einer virtuellen failover-ip macht. diese failover-ip ist die, die man dann in der dhcp config und in den statisch konfigurierten geraeten als dns server eintraegt. eine der beiden pi-hole instanzen laeuft immer als “master” und beantwortet alle anfragen. sobald dieser nicht verfuegbar ist, schnappt sich der “slave” diese virtuelle failover-ip und beantwortet die dns anfragen.
damit hat man zwar immernoch das problem mit dem synchronisieren der config dateien und auch den verfaelschten statistiken und auswertungen, was aber wenigstens nur im ernstfall eintritt, solange der master nicht erreichbar ist. sobald er wieder erreichbar ist, wird die ip auf diesen zurueck geschwenkt.
ich war mal so frei und hab die konfiguration auf o.g. webseite fast genauso uebernommen:
1 . um zu erlauben, dass ip-adressen auch auf nicht lokale schnittstellen zugewiesen werden duerfen, ist eine kleine anpassung auf maste und slave node notwendig:
echo "net.ipv4.ip_nonlocal_bind = 1" >> /etc/sysctl.conf sysctl -p |
2. auf beiden nodes das paket “keepalived” installieren und sicherstellen, dass der auch nach einen boot startet:
apt-get install keepalived systemctl enable keepalived.service |
3. keepalived konfiguration master (datei /etc/keepalived/keepalived.conf)
global_defs {
notification_email {
alerts@domain.de # Benachrichtigungs Zieladresse(n)
}
notification_email_from keepalived@pihole1.domain.de # Benachrichtigungs Quelladresse
smtp_server localhost # SMTP Serveradresse
smtp_connect_timeout 30 # Timeout zum SMTP Server
router_id pihole1 # Eindeutige ID wie z.B. HOSTNAME
script_user root # Benutzer der Notify Scripte
enable_script_security # Script Sicherheit einschalten
}
vrrp_instance PIHOLE {
state MASTER
interface wlan0 # Genutztes Interface
virtual_router_id 51 # ID der Route
priority 150 # Master Prio 150, Backup Prio 50
advert_int 5 # Intervall der VRRP Pakete
smtp_alert # E-Mail Benachrichtigung aktiviren
unicast_src_ip 192.168.1.x # Unicast Quelladresse
unicast_peer {
192.168.1.x # Unicast Zieladresse(n)
}
authentication {
auth_type PASS # Authentifizierungs Typ
auth_pass xxxxxxxxxxxx # Authentifizierungs Passwort
}
virtual_ipaddress {
192.168.1.10/24 # Virtuelle Failover IP-Adresse
}
# notify_master "" # Notify Script für den Master Status (einkommentieren, wenn genutzt wird)
# notify_backup "" # Notify Script für den Backup Status (einkommentieren, wenn genutzt wird)
# notify_fault "" # Notify Script für den Fehler Status (einkommentieren, wenn genutzt wird)
} |
4. keepalived konfiguration slave (datei /etc/keepalived/keepalived.conf)
global_defs {
notification_email {
alerts@domain.de # Benachrichtigungs Zieladresse(n)
}
notification_email_from keepalived@pihole2.domain.de # Benachrichtigungs Quelladresse
smtp_server localhost # SMTP Serveradresse
smtp_connect_timeout 30 # Timeout zum SMTP Server
router_id pihole2 # Eindeutige ID wie z.B. HOSTNAME
script_user root # Benutzer der Notify Scripte
enable_script_security # Script Sicherheit einschalten
}
vrrp_instance PIHOLE {
state BACKUP
interface wlan0 # Genutztes Interface
virtual_router_id 51 # ID der Route
priority 50 # Master Prio 150, Backup Prio 50
advert_int 5 # Intervall der VRRP Pakete
smtp_alert # E-Mail Benachrichtigung aktiviren
unicast_src_ip 192.168.1.x # Unicast Quelladresse
unicast_peer {
192.168.1.x # Unicast Zieladresse(n)
}
authentication {
auth_type PASS # Authentifizierungs Typ
auth_pass xxxxxxxxxxxx # Authentifizierungs Passwort
}
virtual_ipaddress {
192.168.1.10/24 # Virtuelle Failover IP-Adresse
}
# notify_master "" # Notify Script für den Master Status (einkommentieren, wenn genutzt wird)
# notify_backup "" # Notify Script für den Backup Status (einkommentieren, wenn genutzt wird)
# notify_fault "" # Notify Script für den Fehler Status (einkommentieren, wenn genutzt wird)
} |
5. testen der installation
dazu erstmal auf beiden nodes den dienst neu starten:
systemctl restart keepalived.service |
ip a ls
...
inet 192.168.1.10/24 scope global secondary wlan0
valid_lft forever preferred_lft forever
... |
dann auf dem master den keepalived stoppen:
systemctl stop keepalived.service |
die ip-adresse sollten dann sofort auf dem slave verfuegbar sein. in meinem netz habe ich beim pingen der failover-ip ca 4 bis 5 verlorene pakete. das sollte verschmerzbar sein.
bind pi-hole-FTL to certain ip addresses
to bind pihole-FTL to certain ip adresses, you need to add parameters to dnsmasq. if not exist, create a file /etc/dnsmasq.d/99-my-settings.conf with the following settings:
listen-address=127.0.0.1,10.10.60.9,10.10.61.9,10.10.66.9 bind-interfaces |
restart pihole-FTL and verify the result
root@ph:~# netstat -nltup Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name [...] tcp 0 0 10.10.61.9:80 0.0.0.0:* LISTEN 762/lighttpd tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1752/pihole-FTL tcp 0 0 10.10.61.9:53 0.0.0.0:* LISTEN 1752/pihole-FTL tcp 0 0 10.10.60.9:53 0.0.0.0:* LISTEN 1752/pihole-FTL tcp 0 0 10.10.66.9:53 0.0.0.0:* LISTEN 1752/pihole-FTL [...] |
windows: close open file handles
@echo off SET WORKSPACE=C:\Domino\bin\jvm for /f "tokens=3,6,8 delims=: " %%i in ('"%~dp0handle.exe" /accepteula %WORKSPACE% ^| findstr /I %WORKSPACE%') do "%~dp0handle.exe" -c %%j -y -p %%i" |
