Пе­репе­чата­но из жур­на­ла "Ха­кер"

При на­личии Ac­ti­ve Di­rec­to­ry или сер­ве­ра ка­тало­гов оп­ти­маль­ным ва­ри­ан­том бу­дет ис­поль­зо­вание еди­ного хра­нили­ща. При боль­шом ко­личест­ве поль­зо­вате­лей та­кой ва­ри­ант уп­ро­ща­ет ад­ми­нист­ри­рова­ние, так как не нуж­но для каж­до­го юзе­ра соз­да­вать еще и учет­ную за­пись на прок­си. Для ра­боты с AD есть две схе­мы: аутен­ти­фика­ция с ис­поль­зо­вани­ем Ker­be­ros + Sam­ba (win­bind) или по­луче­ние ин­форма­ции об учет­ных за­писях при по­мощи LDAP. Пер­вый ва­ри­ант счи­та­ет­ся офи­ци­аль­ным и под­робно рас­пи­сан на сай­те про­ек­та (wi­ki.squ­id-ca­che.org/Con­fi­gExamp­les/Win­dowsA­ut­henti­cati­onNTLM). По­это­му бу­дем раз­би­рать­ся со вто­рым. Это нес­коль­ко бо­лее уни­вер­саль­ный спо­соб, так как его мож­но ис­поль­зо­вать с лю­бым LDAP-сер­ве­ром, вро­де OpenL­DAP. Для ра­боты че­рез LDAP сле­ду­ет за­вес­ти от­дель­ную учет­ную за­пись (пусть это бу­дет squ­idp­ro­xy). При­чем, для AD мож­но ис­поль­зо­вать учет­ную за­пись с ми­ниму­мом при­виле­гий. До­мен для при­мера возь­мем do­ma­in.com.

Для на­чала про­веря­ем, ви­дит ли мо­дуль squ­id_ldap_auth наш сер­вер:

$ /usr/lib/squ­id3/squ­id_ldap_auth -v 3 -b \

"cn=squ­idp­ro­xy,dc=do­ma­in,dc=com" -f "uid=%s" do­ma­in.com

В от­вет на зап­рос вво­дим стро­ку в ви­де – «поль­зо­ватель па­роль». Ес­ли по­луча­ем OK, мож­но ид­ти даль­ше. Вмес­то име­ни конт­рол­ле­ра до­мена мож­но ука­зать его IP-ад­рес. Вто­рой ва­ри­ант про­вер­ки – с по­мощью ути­литы по­ис­ка ldap­se­arch, ко­торая вхо­дит в па­кет ldap-utils. При подк­лю­чении к AD мож­но ис­поль­зо­вать вмес­то «cn=squ­idp­ro­xy,dc=do­ma­in,dc=com» бо­лее удоб­ный ва­ри­ант за­писи в ви­де squ­idp­ro­xy@do­ma­in.com. В AD имя учет­ной за­писи по­луча­ет­ся при по­мощи «sA­MAc­co­unt­Na­me=%s», а в LDAP ис­поль­зу­ем «cn=%s». Дру­гих от­ли­чий нет.

Ес­ли пла­ниру­ет­ся аутен­ти­фика­ция не толь­ко по поль­зо­вате­лям, но и по груп­пе, про­веря­ем дос­тупность групп:

$ /usr/lib/squ­id3/squ­id_ldap_gro­up -R -b "dc=do­ma­in,dc=com" \

-f "(&(cn=%s)(mem­be­rOf=cn=%s,cn=Users, dc=do­ma­in,dc=com))" \

-D squ­idp­ro­xy@do­ma­in.com -w па­роль -h do­ma­in.com

На зап­рос вво­дим стро­ку – «ло­гин груп­па». С по­мощью па­рамет­ра '–w' ука­зыва­ет­ся па­роль для дос­ту­па поль­зо­вате­ля squ­idp­ro­xy к LDAP-сер­ве­ру.

Пе­рехо­дим не­пос­редс­твен­но к наст­рой­кам Squ­id. Фак­ти­чес­ки в кон­фиг squ­id.conf нуж­но внес­ти все­го две за­писи и ус­та­новить раз­ре­шения:

auth_pa­ram ba­sic prog­ram /usr/lib/squ­id3/squ­id_ldap_auth -R -D squ­idp­ro­xy squ­idp­ro­xy@do­ma­in.com –w па­роль -b "cn=squ­idp­ro­xy,dc=do­ma­in,dc=com" -f "sA­MAc­co­unt­Na­me=%s" do­ma­in.com

# Ес­ли нуж­ны раз­ре­шения на ос­но­вании групп, то подк­лю­ча­ем и внеш­нюю груп­пу

ex­ternal_acl_ty­pe ldap_gro­up %LO­GIN /usr/lib/squ­id3/squ­id_ldap_gro­up -R -b "dc=do­ma­in,dc=com" -f "(&(cn=%v)(mem­be­rOf=cn=%a,dc=do­ma­in,dc=com))" -D squ­idp­ro­xy@do­ma­in.com -W па­роль do­ma­in.com

Фор­мат этих ко­манд опи­сан в до­кумен­та­ции к Squ­id. Здесь за­да­ем %LO­GIN. Тог­да поль­зо­ватель пе­ред про­вер­кой на при­над­лежность к груп­пе бу­дет аутен­ти­фици­рован. Не­кото­рые LDAP-сер­ве­ра для пе­реда­чи па­роля ис­поль­зу­ют TLS. Что­бы под­ру­жить­ся с ни­ми, дос­та­точ­но до­бавить в ко­ман­ды па­раметр '–Z'.

Те­перь в squ­id.conf до­писы­ва­ем пра­вила:

auth_pa­ram child­ren 5

auth_pa­ram ba­sic re­alm Squ­id pro­xy-ca­ching web ser­ver

auth_pa­ram ba­sic cre­den­ti­alsttl 2 ho­urs

acl ldap_gro­up pro­xy_auth RE­QU­IRED

http_ac­cess al­low ldap_gro­up

http_ac­cess al­low lo­cal­host

http_ac­cess de­ny all

Пос­ле пе­реза­пус­ка Squ­id все поль­зо­вате­ли, вхо­дящие в ука­зан­ную груп­пу, бу­дут вы­ходить в ин­тернет.