[Gentoo] pam_abl werkt niet?

[Verwijderd]

Dames en heren,

Zoals al in de topic naam staat heb ik problemen met pam_abl. Ik draai gentoo, en houd deze netjes up to date met emerge. Gentoo zelf kent pam_abl niet, dus deze heb ik met de hand binnen gehaald, gecompileerd en geinstalleerd (niet moeilijk: make && make install).

Ik heb dit gedaan omdat ik de nodige pogingen langs heb zien komen om mijn SSH servertje via brute force binnen te komen. Dat wil ik uiteraard graag voorkomen en buiten de voor de hand liggende oplossingen (geen root toestaan op SSH, alleen v2 toestaan, etc) wilde ik het graag nog een stapje verder dichttimmeren.

Ik kwam in mijn zoektocht pam_abl tegen. Mijn configuratie files staan hieronder. Ik weet dat nu pam_abl twee keer wordt aangeroepen als je met ssh binnen probeert te komen, maar dat lijkt me op het eerste gezicht geen probleem. Het grote probleem is dat er geen database wordt aangelegd van authenticatie pogingen, goed of fout. Deze files zouden in /var/lib/abl moeten komen te staan, deze directory bestaat. Ik heb 'em voor test ook maar a+rw gegeven maar ook dit helpt niet. Ik heb de debug switch aangezet maar zie hier ook geen foutmeldingen in langs komen. Ik snap 'em dus gewoon even niet meer..... Wat doe ik fout? De man pages van pam_abl blinken niet uit in duidelijkheid en er is vrijwel geen verdere info over te vinden...

code:

#%PAM-1.0

auth       required     /lib/security/pam_env.so
auth       required     /lib/security/pam_abl.so config=/etc/security/pam_abl.conf
auth       sufficient   /lib/security/pam_unix.so likeauth nullok shadow
auth       sufficient   /lib/security/pam_ldap.so use_first_pass
auth       required     /lib/security/pam_deny.so

account    sufficient   /lib/security/pam_ldap.so
account    sufficient   /lib/security/pam_unix.so
account    sufficient   /lib/security/pam_deny.so

password   required     /lib/security/pam_cracklib.so retry=3
password   sufficient   /lib/security/pam_unix.so nullok md5 shadow use_authtok
password   sufficient   /lib/security/pam_ldap.so use_authtok
password   required     /lib/security/pam_deny.so

session    required     /lib/security/pam_limits.so
session    required     /lib/security/pam_unix.so
session    required     /lib/security/pam_mkhomedir.so skel=/etc/skel umask=0
session    optional     /lib/security/pam_ldap.so

code:

#%PAM-1.0

auth       sufficient   /lib/security/pam_ldap.so use_first_pass
auth       required     /lib/security/pam_abl.so config=/etc/security/pam_abl.conf
auth       required     pam_stack.so service=system-auth
auth       required     pam_shells.so
auth       required     pam_nologin.so
account    sufficient   /lib/security/pam_ldap.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth

code:

# /etc/security/pam_abl.conf
# debug
host_db=/var/lib/abl/hosts.db
host_purge=1d
host_rule=*:10/1h,30/1d
user_db=/var/lib/abl/users.db
user_purge=1d
user_rule=*:3/10m

[ Voor 1% gewijzigd door Verwijderd op 12-04-2005 11:21 . Reden: Schoonheidsfoutjes ]

[irondog]

Je hebt de debug flag uitgecommenteerd

Welke syslogger gebruik je?

[Verwijderd]

Ik gebruik syslog-ng, maar ik had de debug flag in de pam.d config files staan. In de system logs krijg ik alleen het volgende te zien als een user foutief inlogt:

code:

Apr 11 13:53:10 firewall pam_abl[5958]: Checking host <hostname>
Apr 11 13:53:10 firewall pam_abl[5958]: Checking user <username>
Apr 11 13:53:24 firewall pam_abl[5967]: Checking host <hostname>
Apr 11 13:53:24 firewall pam_abl[5967]: Checking user <username>
Apr 11 13:53:36 firewall pam_abl[5976]: Checking host <hostname>
Apr 11 13:53:36 firewall pam_abl[5976]: Checking user <username>
Apr 11 13:53:48 firewall pam_abl[5985]: Checking host <hostname>
Apr 11 13:53:48 firewall pam_abl[5985]: Checking user <username>

De debug flag werkt dus wel, maar ik zie niet waarom ie geen database files aanmaakt (en dus registreert hoe en wat). In de bovenstaande voorbeelden heb ik expres diverse keren een foutief password ingevoerd. Ik heb even de hostname en username 'gecensureerd'...

[ Voor 6% gewijzigd door Verwijderd op 14-04-2005 11:01 ]

[Verwijderd]

*nudge nudge, kick kick*

Als iemand anders een goed idee heeft om vrij eenvoudig SSH te blokkeren indien mensen met een hele ris user IDs proberen in te breken, ben ik ook geholpen!

[ Voor 75% gewijzigd door Verwijderd op 14-04-2005 11:10 ]

[Verwijderd]

*kick* laatste poging

[Verwijderd]

Uhm, iets van een onderstaande constructie mischien?:

code:

for each line in de_logfile_waarin_de_failed_logins_staan:
     ip = filter_het_ip_adres_uit_de_regel
     voeg_toe_aan_blocklist(ip)
herlaad blocklist in firewall

Zo moeilijk is het niet imho.

[laurencevde]

totdat je zelf per ongeluk een verkeerd wachtwoord intypt

[Verwijderd]

mja, dat is een risico wat er altijd inzit. Exact hetzelfde heb je met pam_abl. Gelukkig is het vrij eenvoudig te omzeilen door een exceptie aan te maken voor jouw username (of alle valid users in /etc/passwd).

[Verwijderd]

Verwijderd schreef op dinsdag 19 april 2005 @ 14:31:
Uhm, iets van een onderstaande constructie mischien?:

code:

for each line in de_logfile_waarin_de_failed_logins_staan:
     ip = filter_het_ip_adres_uit_de_regel
     voeg_toe_aan_blocklist(ip)
herlaad blocklist in firewall

Zo moeilijk is het niet imho.

Het nadeel wat ik hieraan zie is dat dit een scriptje is wat via een cronjobje draait, en niet 'as it happens', als je snapt wat ik bedoel. pam_abl pikt meteen op dat er iemand bezig is. Ik zal evengoed wel even kijken of het bovenstaande werkt voor mij.. Evengoed bedankt in ieder geval..

[Verwijderd]

Verwijderd schreef op maandag 25 april 2005 @ 15:18:
Het nadeel wat ik hieraan zie is dat dit een scriptje is wat via een cronjobje draait, en niet 'as it happens', als je snapt wat ik bedoel. pam_abl pikt meteen op dat er iemand bezig is. Ik zal evengoed wel even kijken of het bovenstaande werkt voor mij.. Evengoed bedankt in ieder geval..

Oh daar heb je absoluut gelijk in. Maar als het goed zijn die valse logins naar niet bestaande users, dus is het niet zo'n ramp als je 1~2 x per dag een cronjobje laat lopen. Als je wilt, zou je nog met iets als swatch semi-realtime dit scriptje kunnen aftrappen. Maar nogmaals, het is geneuzel in de marge, als de failed logins naar niet bestaande users gaan...

[Verwijderd]

Verwijderd schreef op maandag 25 april 2005 @ 16:17:
Oh daar heb je absoluut gelijk in. Maar als het goed zijn die valse logins naar niet bestaande users, dus is het niet zo'n ramp als je 1~2 x per dag een cronjobje laat lopen. Als je wilt, zou je nog met iets als swatch semi-realtime dit scriptje kunnen aftrappen. Maar nogmaals, het is geneuzel in de marge, als de failed logins naar niet bestaande users gaan...

En daar heb jij weer gelijk in.... Goed.. weer wat om over na te denken.. Dank!