Squid - Bizonyos oldalak?

Debian GNU/Linux

hello!

a kovetkezo erdekes problemam van, squid-en keresztul nem jon be a https://docs.google.com mi tobb a logban sem latom a kerest...minden mas site mukodik...

ugyanazon a vonalon direktben proxy nelkul mukodik...

otlet?

koszi!

konfig:

http_port 192.168.132.4:3128

visible_hostname adsl-inet-firewall.xyz.hu

hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY

cache_mem 100 MB
minimum_object_size 0 KB
maximum_object_size 50 MB
cache_replacement_policy heap LFUDA
cache_swap_low 90
cache_swap_high 95
memory_replacement_policy lru
cache_dir ufs /var/spool/squid3 10000 16 256
maximum_object_size_in_memory 50 KB
logfile_rotate 10
memory_pools off
pipeline_prefetch on
shutdown_lifetime 1 second
quick_abort_min 0 KB
quick_abort_max 0 KB
log_icp_queries off
client_db off
buffered_logs on
half_closed_clients off

# refresh patterns

# windows updates
refresh_pattern http://.*\.windowsupdate\.microsoft\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://.*\.update\.microsoft\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://download\.microsoft\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://windowsupdate\.microsoft\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://.*\.download\.windowsupdate\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://office\.microsoft\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://w?xpsp[0-9]\.microsoft\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://w2ksp[0-9]\.microsoft\.com/ 0 80% 20160 reload-into-ims

# linux updates
refresh_pattern http://.*\.archive\.ubuntu\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://(ftp|http)[0-9]*\.[a-z]+\.debian\.org/ 0 80% 20160 reload-into-ims

refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320

# end refresh patterns

acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl xyz_alllan src 192.168.0.0/16
acl SSL_ports port 443 # https
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl CONNECT method CONNECT
acl purge method PURGE

acl blocksites url_regex "/etc/squid3/squid-block.acl"
http_access deny blocksites

http_access allow localhost
http_access allow xyz_alllan
http_access deny all

#Hardening

icp_port 0
htcp_port 0
icp_access deny all
htcp_access deny all

snmp_port 0
snmp_access deny all

  • 8675 megtekintés

( Swifty v | 2013. 02. 03., v – 16:52 )

Nem látom, hogy httpS-re is bekapcsoltad volna...
--
Debian Linux rulez... :D

( FBK | 2013. 02. 07., cs – 13:37 )

kb belottem a problemat, ha egy http oldal https --re redirectel, akkor nem jon be az adott site.

--
FBK

http_port x.y.z.x:3128

visible_hostname adsl-inet-firewall.xyz.hu

hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY

cache_mem 100 MB
minimum_object_size 0 KB
maximum_object_size 50 MB
cache_replacement_policy heap LFUDA
cache_swap_low 90
cache_swap_high 95
memory_replacement_policy lru
cache_dir ufs /var/spool/squid3 10000 16 256
maximum_object_size_in_memory 50 KB
logfile_rotate 10
memory_pools off
pipeline_prefetch on
shutdown_lifetime 1 second
quick_abort_min 0 KB
quick_abort_max 0 KB
log_icp_queries off
client_db off
buffered_logs on
half_closed_clients off

# refresh patterns

# windows updates
refresh_pattern http://.*\.windowsupdate\.microsoft\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://.*\.update\.microsoft\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://download\.microsoft\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://windowsupdate\.microsoft\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://.*\.download\.windowsupdate\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://office\.microsoft\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://w?xpsp[0-9]\.microsoft\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://w2ksp[0-9]\.microsoft\.com/ 0 80% 20160 reload-into-ims

# linux updates
refresh_pattern http://.*\.archive\.ubuntu\.com/ 0 80% 20160 reload-into-ims
refresh_pattern http://(ftp|http)[0-9]*\.[a-z]+\.debian\.org/ 0 80% 20160 reload-into-ims

refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320

# end refresh patterns

acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl cegnev_alllan src 192.168.0.0/16

acl SSL_ports port 443 # https
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https

acl CONNECT method CONNECT
acl purge method PURGE

acl blocksites url_regex "/etc/squid3/squid-block.acl"
http_access deny blocksites

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow CONNECT SSL_ports
http_access allow localhost
http_access allow cegnev_alllan
http_access deny all

#Hardening

icp_port 0
htcp_port 0
icp_access deny all
htcp_access deny all

snmp_port 0
snmp_access deny all

--
FBK

"És hol, hogyan van benne?"
Az eredetiben ennél a sornál: 

http_access allow xyz_alllan

Az új verziónál ez a sor engedné át: 

http_access allow CONNECT SSL_ports

Teljesen biztos vagy benne, hogy explicite engedélyezni kell, és ha külön nem engeded a CONNECT-et, akkor az nem megy át? Mert a dokumentáció nem szól a CONNECT kivételezettségéről, illetve a Squid default konfigjában a CONNECT-et a nem SSL portokra tiltja. Ebből következően a http_access önmagában engedi az SSL portokra a CONNECT-et. Ezt egyébként ki is próbálhatod.

"Na ennek fuss neki még 1x"
Attól eltekintve, hogy egy ilyen konstukció látszólag értelmetlen, még nem feltétlen az. A nem megfelelő portokra nem engedi a CONNECT-et, de a megfelelőekre igen, más feltételektől függetlenül. Ennek jelen esetben akkor van értelme, ha olyan helyről is kell CONNECT megfelelő portra, mely nem a localhost, illetve nem a cegnev_alllan része. Ugye ahogy írtad már te is, fontos a sorrend.

Na akkor én mondom: :D

http_access deny !Safe_ports -> Dobj el MINDENT ami nem a Safe_ports irányába megy !!! AZAZ AZ SSL-t is !!!

http_access deny CONNECT !SSL_ports -> Ne engedj CONNECT-et nem SSL_port-on.

http_access allow CONNECT SSL_ports -> Engedj CONNECT-et SSL_port-on.

Szóval szerintem az "első" acl megöli az SSL kéréseid.
A másik kettő meg igazából ugyanaz...

--
Debian Linux rulez... :D

"Szóval szerintem az "első" acl megöli az SSL kéréseid"
"http_access deny !Safe_ports -> Dobj el MINDENT ami nem a Safe_ports irányába megy !!! AZAZ AZ SSL-t is !!!"
Érdekes, én FBK fentebbi hozzászólásában látok olyan sort, hogy "acl Safe_ports port 443 # https", tehát az a bizonyos HTTPS-es TCP/443 része a Safe_ports nevű ACL-nek, azaz azt tiltjuk, ami nem 443 (vagy 21 vagy 80), ebből következően ezen a http_access soron nem akadhat fenn.

"http_access deny CONNECT !SSL_ports -> Ne engedj CONNECT-et nem SSL_port-on."
Pontosan.

"http_access allow CONNECT SSL_ports -> Engedj CONNECT-et SSL_port-on."
Így van.

"A másik kettő meg igazából ugyanaz..."
Nem feltétlen ugyanaz. Az egyik azt mondja, hogy bárhonnan jön a CONNECT kérés, ha nem a három port egyikére tart, akkor nem mehet. A másik pedig azt jelenti, hogy akkor is mehet a CONNECT a három port egyikére, ha az nem a 192.168.0.0/16-ból vagy a 127.0.0.1-ről jön, mert például van egy 172.16.17.0/24 címtartományban lévő gépe is. A "deny CONNECT !SSL_ports" nélkül nem lenne mindenkire vonatkozó korlátozás a CONNECT-tel használható portokra. Az "allow CONNECT SSL_ports" nélkül pedig a localhost és a 192.168.0.0/16 kliensek kivételével nem juthatna ki máshonnan kérés. Nem tudjuk, hogy FBK-nál van-e más IP tartomány, ahonnan kellene tudnia használni a CONNECT metódussal elérhető szolgáltatásokat, tehát lehet, hogy az ő esetében felesleges, és lehetne ezt egyszerűbben is. De etől még a két sor ebben az adott kontextusban nem ugyanazzal a jelentéssel bír. A végén lévő dupla "deny all" közül viszont tényleg felesleges az egyik (ha szigorűan nézzük, akkor mindkettő), csak hogy találjunk egy egyértelműen felesleges sort is a http_access-ek között.

 
De a probléma nem itt lakozik. Ugyanis mielőtt kérted volna, hogy tegye be a "http_access allow CONNECT SSL_ports" sort, a nyitó hozzászólásban abban az 5 sorban nem volt még szó (értsd: nem volt rájuk hivatkozás) a Safe_ports ACL-ről, vagy a CONNECT metódussal foglalkozó ACL-ről. Ott a file-ban megadott URL-ek tiltása után azonnal a localhost (src 127.0.0.1/32) és a xyz_alllan (src 192.168.0.0/16) engedélyezése következett, porttól és metódustól függetlenül. Úgy sem ment, ez volt az eredeti gond, és mivel az "allow xyz_alllan" beengedi az összes 192.168.0.0/16 felől induló kérést függetlenül a metódustól vagy a porttól, így hát érthető, hogy ezek explicit engedélyezése sem oldotta meg.

Igazad van abban, hogy a Safe_ports-ba nem vettem be a 443-at... :D

Viszont szerintem az alábbi két sor ugyanazt adja a jelenlegi konfigban... És sehol sem látom a source-ra vonatkozó szűréseket... http://hup.hu/node/121734#comment-1567967 (Mert ugye ezt feszegetted...)
http_access deny CONNECT !SSL_ports
http_access allow CONNECT SSL_ports

Azt hiszem, hogy a konfiggal már nincs hiba... Kérdés, hogy a kliens tudja-e, hogy proxy-val beszélget? Azaz meg van-e adva neki a beállításokban, hogy használja? Mert amíg a sima http-t el lehet akár iptables-sel is kapni, addig a https-nél már ez nem mehet... Ilyenkor meg kell mondani a kliensnek, hogy itt a proxy, használd !!! :D

--
Debian Linux rulez... :D

( Umath v | 2013. 02. 07., cs – 17:19 )

A kliens oldalon a böngészőben be van állítva a https proxy is?