squid - "downstream" authentikáció

Linux-security

Sziasztok!

Van egy hálózatunk, ahol egy squid proxy NTLM authentikációt végez. Az NTLM authentikációból nyert adatokat továbbítja a Messagelabs szerverek felé, ahol speciális HTTP headerökben szerepel a felhasználói név és a forrás IP cím.
http://blog.periodicfailure.com/?p=22

Ügyfelünk szeretné ezt a felállást tovább bonyolítani.
A squid proxy elé el kell helyeznünk egy tűzfalat, ami IPS és alkalmazás szűrési funkciókat fog ellátni. A kliensek először ehhez a tűzfalhoz csatlakoznak, majd a squid proyxhoz. Az NTLM authentikációt azonban nem tudjuk átjátszani a tűzfalon (mivel ő is proxyként kezeli a kapcsolatokat...).

A tűzfal képes authentikálni a felhasználókat, és a HTTP headerbe berakni egy fieldet:
Proxy-Authorization: Basic YmlnYm9zczptYW5hZ2VtZW50

Azt szeretnénk, ha a squid elfogadná az ilyen kapcsolatokat, authentikált kapcsolatként az adott felhasználóhoz tartozóan, aki a fentebbi stringben van.
Lehetséges ez?

Köszi,
Attila

  • 7365 megtekintés

( phr3ak | 2013. 08. 15., cs – 19:05 )

Az nem lenne megoldás hogy a tűzfal ip-ről minden forgalmat elfogadtok authentikáció nélkül?

igen. en ezt latom jarhato utnak. mint irtam, szerintem ilyet nem tud, de esetleg kerdezhetsz a squid levlistan.

u.i.
ha sikerul megoldani, nagyon orulnek a leirasnak hogy hogy is lett vegul :)
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

Sziasztok!

Megoldottam.

Továbbra is csak a felhasználónév és csak a csoporttagságok vannak továbbítva az UTM-ről.
De Squiden már látom a felhasználót:
1376925511.779 32 192.168.32.33 TCP_MISS/200 536 GET http://www.google-analytics.com/__utm.gif? bigboss DIRECT/173.194.39.165 image/gif
Mivel ez csak egy tesztkörnyezet, ezért bátran idemásolom a konfigot. Gyakorlatilag annyit kellett csinálnom, hogy a basic_fake_auth-ot hívom meg, ami mindenre OK-t ad vissza:)

Egyetlen egy probléma maradt már csak. Nem szeretném, ha valaki a Proxy-Authorization fieldet maga megszerkesztve bárhova is ki tudna menni. Ezért csak egy adott MAC-címről szeretném elfogadni a forgalmat. Sajnos azonban a Squid csak az ARP-táblát nézi...
? (192.168.213.1) at 00:50:56:c0:00:08 [ether] on eth0
? (192.168.213.2) at 00:50:56:f1:79:13 [ether] on eth0
? (192.168.32.254) at 00:0c:29:42:f4:eb [ether] on eth1
? (192.168.32.33) at 00:0c:29:97:f2:68 [ether] on eth1
Hiába érkezik a .33 forgalma a 00:0c:29:42:f4:eb MAC-címről, nem engedi tovább (A tűzfal teljesen transzparens módban működik a Squid és a kliensek között, és megtartja a forrás IP-t.)

[config]

auth_param basic program /usr/lib/squid3/basic_fake_auth
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 minutes

#external_acl_type ADS %LOGIN /usr/lib/squid3/wbinfo_group.pl
#acl management external ADS Management

acl manager proto cache_object
acl AuthorizedUsers proxy_auth REQUIRED
acl NETASQ arp 00:0C:29:42:F4:EB
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1

#http_access allow NETASQ
http_access allow AuthorizedUsers
#http_access allow management
http_access allow manager localhost
http_access deny manager
http_access allow localhost
http_access deny all
http_port 3128

coredump_dir /var/spool/squid3
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern (Release|Packages(.gz)*)$ 0 20% 2880
refresh_pattern . 0 20% 4320

[/config]