Kerberos – dokončení konfigurace
Navážeme tam, kde jsme minule skončili. Máme stažený Msktutil pro naši architekturu (na výběr máme amd64 nebo i386, já použiji i386) a balíček si nainstalujeme.
# dpkg -i msktutil_0.4-2_i386.deb
Teď nastal čas si zažádat AD o autorizaci, abychom mohli vytvořit účet počítače pro účely autentizace přes Kerberos. Z důvodů, které jsou popsány v mailing listu Squidu, nyní nepoužíváme jako hostname proxy.domain.internal, ale v minulém díle zmíněný PROXY-K. Důvodem je Samba (potažmo zřejmě Winbind), která pravidelně mění heslo účtu počítače a nám by tím neustále zneplatňovala uložený klíč Kerberose.
# kinit administrator Password for administrator@DOMAIN.INTERNAL:
a zkontrolujeme
# klist
Pokusíme se založit první účet počítače. Podmínkou je také maximální délka 15 znaků. Poslední parametr --enctypes 28 je nutný pouze pro verzi AD 2008.
# msktutil -c -b "CN=COMPUTERS" -s HTTP/proxy.domain.internal -k /etc/squid3/PROXY.keytab --computer-name PROXY-K \ --upn HTTP/proxy.domain.internal --server eupdc1.domain.internal --verbose --enctypes 28
Také existuje možnost, kdy si účet založíme přímo na Windows serveru a pak ho reinicializujeme a exportujeme keytab.
Co vlastně msktutil umí?
- vytvářet účet PC v AD a měnit jeho heslo
- ukládat klíče pro Kerberos a provádět údržbu keytab
Účet počítače v Active Directory, zde je možno ho ručně vytvořit i resetovat
Pokud vše proběhlo dobře, máme v souboru /etc/squid3/PROXY.keytab klíče. Zajistíme si, aby mohl Squid soubor číst.
# chgrp proxy /etc/squid3/PROXY.keytab # chmod g+r /etc/squid3/PROXY.keytab
Odhlásíme se.
# kdestroy
Jako test funkčnosti můžeme resetovat na Windows serveru účet počítače a zkusit aktualizovat keytab. Pozor, hostname malými písmeny.
# msktutil --auto-update --verbose --computer-name proxy-k -k /etc/squid3/PROXY.keytab
Čas od času je potřeba aktualizovat účet hosta v AD, proto si do /etc/crontab přidáme to, co jsme si teď vyzkoušeli
00 4 * * * msktutil --auto-update --verbose --computer-name proxy-k | logger -t msktutil
Posledním úkolem u konfigurace Kerberose je říci Squidu, kde najde keytab.
# echo "export KRB5_KTNAME=/etc/squid3/PROXY.keytab" | tee /etc/default/squid3
NTLM
Nastal čas doinstalovat Sambu a Winbind, ten nám zajistí NTLM autentizaci.
# apt-get install samba winbind samba-common-bin
a pro jistotu je zatím zastavíme
# service smbd stop
smbd stop/waiting
# service winbind stop
* Stopping the Winbind daemon winbind [ OK ]
následně upravíme sekci [global] v /etc/samba/smb.conf
#GLOBAL PARAMETERS [global] workgroup = DINTERNAL realm = DOMAIN.INTERNAL preferred master = no server string = squid proxy server security = ADS encrypt passwords = yes log level = 3 log file = /var/log/samba/%m max log size = 50 printcap name = cups printing = cups winbind enum users = Yes winbind enum groups = Yes winbind use default domain = Yes winbind nested groups = Yes winbind trusted domains only = Yes winbind cache time = 3600 winbind separator = + ;template primary group = “Domain Users” template shell = /bin/bash
a přidáme náš server do domény
# net ads join -U Administrator
Úspěch tohoto kroku poté ověříme spuštěním obou služeb a použitím následujícího příkazu. Zde by neměl být žádný problém.
# wbinfo -t checking the trust secret for domain DINTERNAL via RPC calls succeeded
Pokus o ověření standardním doménovým uživatelem user vypadá také pořádku.
# wbinfo -a user --verbose Enter user's password: plaintext password authentication succeeded Enter user's password: challenge/response password authentication succeeded
Teď ještě přidáme proxy do skupiny winbindd_priv, aby mohla číst z adresáře /var/run/samba/winbindd_privileged.
# gpasswd -a proxy winbindd_priv
A posledním krokem u konfigurace NTLM je zabezpečení pravidelné aktualizace hesla u našeho druhého účtu hosta. Některé zdroje uvádí, že to Samba dělá samostatně, častější změnou každopádně ničemu neuškodíme. Vložíme opět do /etc/crontab.
05 4 * * * net rpc changetrustpw -d 1 | logger -t changetrustpw
Basic autentizace
Základní ověřování používá protokol LDAP a pro jeho účely si musíme nachystat uživatelský účet v doméně. Tento nebude vyžadovat žádná speciální oprávnění, naopak, měl by mít práva co nejmenší, protože jde pouze o možnost číst údaje o objektech v AD. Dále je potřeba nastavit, aby mu nevypršelo heslo, protože ho budeme mít staticky uložené v souboru na našem proxy serveru. V našem případě se bude jmenovat prostě user.
Vhodné nastavení uživatele v AD, možná by stačilo členství i v Domain Guests
Vytvoříme soubor s heslem a nastavíme odpovídající oprávnění pro přístup.
# echo 'tajne_HeSlo987*#' > /etc/squid3/ldappass.txt # chmod o-r /etc/squid3/ldappass.txt # chgrp proxy /etc/squid3/ldappass.txt
A celé to musíme zabalit
Wrapper bude nutné zkompilovat ze zdrojových kódů, ale nejdříve potřebujeme hlavičkové soubory jádra.
# apt-get install build-essential linux-headers-$(uname -r)
pak na něj konečně přijde řada
# cd /usr/local/src/ # wget "http://downloads.sourceforge.net/project/squidkerbauth/negotiate_wrapper/negotiate_wrapper-1.0.1/negotiate_wrapper-1.0.1.tar.gz" # tar -xvzf negotiate_wrapper-1.0.1.tar.gz # cd negotiate_wrapper-1.0.1/ # ./configure && make && make install
Squid
Squid už jsme si nainstalovali v minulém díle, teď nás tedy čeká úprava jeho konfigurace v souboru /etc/squid3/squid.conf
### Negotiate Kerberos a NTLM autentizace auth_param negotiate program /usr/local/bin/negotiate_wrapper -d --ntlm /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=DINTERNAL --kerberos /usr/lib/squid3/squid_kerb_auth -d -s GSS_C_NO_NAME auth_param negotiate children 10 auth_param negotiate keep_alive off ### NTLM autentizace auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=DINTERNAL auth_param ntlm children 10 auth_param ntlm keep_alive off ### Basic autentizace přes LDAP auth_param basic program /usr/lib/squid3/squid_ldap_auth -R -b "dc=DOMAIN,dc=INTERNAL" -D user@domain.internal -W /etc/squid3/ldappass.txt -f sAMAccountName=%s -h eupdc1.europapier.internal auth_param basic children 10 auth_param basic realm Internet Proxy auth_param basic credentialsttl 1 minute ### definujeme si access list pro autentizační metody acl auth proxy_auth REQUIRED ### a konečně vynutíme ověřování klientů http_access deny !auth http_access allow auth ### tohle bude vždy na konci http_access http_access deny all
Jde o velice minimalistickou konfiguraci vhodnou na začátek při testování funkce proxy serveru. S pomocí acl lze přesně definovat přístupy uživatelů, lze použít i externí přístupové skupiny přímo z Active Directory a ošetřit výjimky. Toto téma by vydalo na další případný článek. Po úpravách si spustíme/restartujeme náš Squid.
# service squid3 restart
squid3 stop/waiting
squid3 start/running, process 8688
A teď se vyzkoušíme připojit z nějaké doménové stanice na Internet s použitím našeho nového proxy serveru. Pokud se objeví hláška vyžadující přihlášení anebo se neobjeví nic a Internet stejně nejde, je něco špatně. (Tedy pokud jste si mezitím neukopli síťový kabel.) Při úspěšném připojení se následně podíváme do /var/log/squid3/access.log a pokud uvidíte například toto, máte vyhráno!
1347514512.995 43 192.168.21.52 TCP_MISS/200 1470 GET http://gidnes.cz/u/n4/shadeMid.gif masekd DIRECT/194.79.52.198 image/gif
Doménové jméno uživatele máme konečně v logu a teď si připravíme hezčí výstup.
Statistiky přístupů
Jak jsem na začátku slíbil, nastal váš čas na výběr oblíbeného web serveru. Já zvolil pro účely předvedení webfsd a document root nastavil na /var/www/html/. Pro analýzu logů je také celkem slušný výběr a my si ukážeme Sarg.
# apt-get install sarg
Konfigurace Sargu se usídlí v /etc/sarg, kde nás budou momentálně zajímat pouze soubory sarg.conf a sarg-reports.conf. Statistiky se pravidelně spouštějí cronem, a to už instalace zařídila za nás.
# sarg.conf access_log /var/log/squid3/access.log output_dir /var/www/html/squid-reports
Zde uvádím pouze upravené parametry pro správnou funkci, Sarg potřebuje vědet odkud vzít data a kam je zapsat. Nezapomeňte případně upravit oprávnění na zápis do output_dir. U souboru sarg-report.conf také není moc na vysvětlování.
# sarg-reports.conf
SARG=/usr/bin/sarg
CONFIG=/etc/sarg/sarg.conf
HTMLOUT=/var/www/html/squid-reports
PAGETITLE="Access Reports on $(hostname)"
LOGOIMG=/squid-reports/images/sarg.png
LOGOLINK="http://$(hostname)/"
DAILY=Daily
WEEKLY=Weekly
MONTHLY=Monthly
EXCLUDELOG1="SARG: No records found"
EXCLUDELOG2="SARG: End"
Nebudeme čekat na cron, nějaká data v logu máme, vygenerujeme report hned.
# /usr/sbin/sarg-reports manual
Výstup poskytuje statistiky přístupů na jednotlivé stránky, TOP uživatele apod. Vše v přehledných tabulkách a grafech.
Náhled vygenerovaných reportů
Kam dál?
Tato ukázka je v podstatě pouze proof-of-concept, při reálném nasazení bychom se museli více zabývat zabezpečením, odladit výkonnostní parametry, mít přehled o SW vybavení na stanicích, které by mohlo mít problémy s tímto „omezením“ přístupu, ošetřit výjimky apod. Teď už ale víme, že to jde.
ČLÁNKY DO MAILU