Restart servisa saslauthd obvezan kod promjene korisničke zaporke

Iako inspiracija za najveći broj članaka na Portalu za sistemce potiče upravo od upita koje zaprimamo na sys.help, od sada ćemo neke vaše upite prenosite nešto direktnije. Pod ovim mislimo da ćemo više pažnje posvetiti konkretnom upitu, te tome u čemu je točno problem. Smatramo da se tako može dodatno naučiti, jer promatranjem tuđih "grešaka u koracima" možemo promijeniti vlastiti način razmišljanja i tako  spriječiti pojavu sličnih problema na vlastitom terenu.

Prvi slučaj je "klasičan", neki korisnik je svoju zaporku proslijedio spamerima, te je preko SASL-a poslužitelj postao centar za slanje spam poruka. Evo što nam je sistemac poslao o učinjenim koracima nakon što je identificirao korisnika:

1. promijenio sam korisniku lozinku za pristup mailu. NIJE POMOGLO
2. zaključao sam korisnikov račun (passwd -l username) NIJE POMOGLO
3. preimenovao sam korisnikovo ime (usermod -d "/home/korisnik2" -m -l korisnik2 korisnik) NIJE POMOGLO

Ne znam što više da poduzmem!? Imate li kakvu ideju da to prekinem.

Ono što nije učinio piše na http://sistemac.carnet.hr/node/752, a to je da nije restartao daemon saslauthd (ne mislimo da bi trebali zapamtiti sve članke ikad objavljene na portalu, naravno). Zašto je to morao učiniti kada je promijenio korisnikovu zaporku, pa i username? Razlog leži u opciji "-c":

$ ps -ef |grep saslauthd
root 917 1 0 Apr15 ? 00:00:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -n 5

Opcija "-c" znači ovo:

 -c      Enable caching of authentication credentials

Dakle, saslauthd u memoriji čuva (kešira) korisničke podatke, te su ostali zapamćeni podaci za korisnika "korisnik", bez obzira što je promijenjen čak i username. Restart servisa rješava problem, jer se stari podaci brišu:

# /etc/init.d/saslauthd restart

Iz ovoga smo naučili da trebamo provjeriti ima li neki servis internu privremenu memoriju, te izbrisati te podatke - što je obično najlakše napraviti restartom servisa.

NADOPUNA: ukoliko rabite autentikaciju korisnika i preko radiusa, ne zaboravite promijeniti i zaporku u LDAP-u, odnosno sustavu AAI@EduHr!

 

Kuharice: 
Kategorije: 
Vote: 
0
No votes yet

Komentari

Da li je onda preporučljivo iskljuciti keširanje korisničkih podataka unutar datoteke /etc/default/saslauthd  i kako bi to utjecalo na ponašanje sustava?

Možete probati i javiti :)

Nije bez veze uvedeno keširanje, ali opet, koliko to korisnika to mi imamo po serveru? BTW, keširanje radi samo do ponovnog restarta...

Drugim riječima, u slučaju da imate napad preko SASL-a, treba se samo sjetiti restartati i saslauthd...