squid3 man-in-the-middle átlátszóban

Linux-haladó

Sziasztok,

szükség lenne blokkolnom bizonyos oldalakat.
Évekig Squid2-t használtam http-re. Amióta pl. a youtbe átköltözött https-re, csak a man-in-the-middle maradt. Ehhez squid3 kell.

Sikerült bekonfigurálnom, DE elvesztettem az átlátszó proxyt, igy a userek könnyen kikerülik.

Most így működik:
ha 3128 a böngésző portja mindenre, akkor http-t szűr a guarddal, az engedélyezett https-t átengedi anélkül, hogy a böngésző tanúsítványért rinyálna (böngészőbe nem is importáltam), a tiltott oldalak tanúsítványhiba miatt nem jelennek meg. Nekünk ez így jó.

De ha "Nincs proxy" a böngészőben, a tiltott https-ek is megjelennek és a squidguard se szűr.

Minden segítő szándékot előre köszönök!!!

squid.conf

acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

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

http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/home/proxy/ssl_cert/myCA.pem
http_port 3129 intercept
https_port 3130 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/home/proxy/ssl_cert/myCA.pem

acl bump_sites dstdomain .youtube.com .youtube.com.mx .facebook.com
ssl_bump none localhost
ssl_bump server-first bump_sites
ssl_bump none all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER

always_direct allow all

cache_mem 2048 MB
cache_dir ufs /squid/cache 20480 16 256
access_log daemon:/var/log/squid3/access.log squid
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 . 0 20% 4320

url_rewrite_program /usr/bin/squidGuard

iptables.rules részlet

*nat
:PREROUTING ACCEPT [15:1212]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [5:382]
-A PREROUTING -p tcp --dport 443 -j ACCEPT
-A PREROUTING -p tcp --dport 80 -j ACCEPT

-A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to-destination 10.247.72.169:3129
-A PREROUTING -i eth1 -p tcp --dport 443 -j DNAT --to-destination 10.247.72.169:3130

-A POSTROUTING -p tcp -s 10.247.72.0/24 -o eth0 --dport 53 -j MASQUERADE
-A POSTROUTING -p udp -s 10.247.72.0/24 -o eth0 --dport 53 -j MASQUERADE
-A POSTROUTING -p tcp -s 10.247.72.0/24 -o eth0 -j MASQUERADE

  • 8906 megtekintés

( bennyh | 2016. 04. 27., sze – 11:36 )

Miért fontos, hogy transzparens proxy legyen? Nem elég simán tiltani, hogy a kliensek direktbe kommunikáljanak 80-as és 443-as portok felé a külvilággal? A Squid akkor is müxik, ha az átjáron van és az átjárón tiltva van a forward (igaz, akkor már nem átjáró :D), de lehet tiltani, hogy csak bizonyos ip címekről forwaldoljon az átjáró. Ha kikapcsolják a proxy elérést a kliensek, akkor nem lesz net, ha meg proxy-n keresztül, akkor meg müxik a szűrés. Domain név szűréshez meg nem kell SSL bump,megy anélkül is, csak a kommunikáció tartalmát nem tudod csekkolni, valamint rendes figyelmeztető üzenetet nem tud küldeni a proxy.

Köszönöm a választ!

Azért fontos transzparens, mert vannak tabletek, ami máshol is kell menjen, nem csak itt.

Hogy érted a "kliensek direktbe kommunikáljanak 80-as és 443-as portok felé a külvilággal"?
ha ezt rakom be, akkor semmi forgalmat nem enged:

-A Inet_to_lnet -p tcp --dport 80 -j DROP
-A Inet_to_lnet -p tcp --dport 443 -j DROP

ahol
# Sajat lancok forgalom iranya alapjan
-A INPUT -i eth0 -j inet_to_fw
-A INPUT -s 10.247.72.0/24 -i eth1 -j lnet_to_fw
-A FORWARD -d 10.247.72.0/24 -i eth0 -o eth1 -j inet_to_lnet
-A FORWARD -s 10.247.72.0/24 -i eth1 -o eth0 -j lnet_to_inet
-A OUTPUT -o eth0 -j fw_to_inet
-A OUTPUT -d 10.247.72.0/24 -o eth1 -j fw_to_lnet

Hú, így kevésbé tiszta nekem saját lánccal, sima Forward esetén meg lehetne adni, hogy alapértelmezetten ne engedje , csak speciális IP címekről, és az nem zavarna a prerouting-ba.

DNS-ben és DHCP-n hirdetett proxy autoconfig script se játszik (egy egyszerű script lokális http szerveren)? vagy túl buták a használt mobileszközök az automatikus felismeréshez?

DNS-ben és DHCP-n hirdetett proxy autoconfig

DHCP option #135 - HTTP Proxy for phone-specific applications. RFC 4578
illetve ezt
DHCP option #15 - Domain Name. RFC 2132
ajánlom figyelmedbe.
a PAC-képes (proxy auto config) böngészők, oprendszerek a http://wpad.DHCP-DOMAIN-NAME/wpad.dat (esetleg smb://WPAD/wpad.dat) helyen keresnek egy JS fájlt (web proxy auto discovery), ld. wiki:Proxy auto-config

dns beállítás akkor kell ha a wpad.domain.int -et meg akarod határozni, melyk webszerveren legyen, vagy ha saját url-t hirdetsz a 135-ös opcióval.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Ne is mond, hányszor szívtam emiatt :)
de már nincs erőm átírni még azt is.

Ha már olvasod, nem tudod, hogyan lehetne a 8000-es portot bent engedni, úgy hogy direktbe mindenféle átalakítás nélkül kommunikáljanak azon egymással a gépek, mert van egy progi, ami állandóan elakad. :)

egymással a gépek

ebből arra következtetek hogy LAN-on belüli forgalomról lenne szó, akkor viszont azt nem korlátozza a gateway tűzfala, nem ér el odáig, csak a switch-eken megy át. vagy nem értem honnan hova megy ez a forgalom?

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( gemnon v | 2016. 04. 27., sze – 11:42 )

-A PREROUTING -p tcp --dport 443 -j ACCEPT
-A PREROUTING -p tcp --dport 80 -j ACCEPT

Ez a kettő micsi, nem semmisé teszi az alatta lévőt (bár rég játszottam iptablessel, nem kellene a végére egy -s 10.247.72.169 , hogy csak a proxyra vonatkozzon)? :)

De ha jól látom akkor a tűzfal doboz más mint a squid dobozod, akkor szerintem más is kell oda.

Pl. kihagyni a squid ip-jét a DNAT-ból (mert saját farkába harap :)) és SNAT is.

iptables -t nat -A PREROUTING -i eth0 -s ! squid-box -p tcp --dport 80 -j DNAT --to squid-box:3128
iptables -t nat -A POSTROUTING -o eth0 -s local-network -d squid-box -j SNAT --to iptables-box

( Zs | 2016. 04. 27., sze – 19:26 )

Első kanyarban a tűzfal szabályokat lenne célszerű tisztába tenni.
1) Ha a PREROUTING láncon minden 443 és 80 port felé menő forgalom ACCEPT target-et kap, akkor a vizsgálat itt befejeződik, a csomag pedig megy tovább a maga útján. Tehát mindenféle további szabály, amely a 80-as és 443-as célportok forgalmával foglalkozik, már soha nem fog teljesülni, mert korábban egy bővebb szabály az összes ilyen csomagot leterelte a láncról. Így gyakorlatilag a redirect nem működik.
2) Bár a transzparens proxy-hoz nincs köze, de miért jó külön szabállyal csak az 53/tcp és 53/udp célportok forgalmát maszkolni, ha egyébként utána ugyanezen szubnet teljes forgalma is maszkolódik? Az utolsó szabály, ami maszkol mindent, maszkolná ezt a forgalmat is.

Az 1-es pontban tökéletesen igazad van. Az igazság az, hogy az utóbbi napokban annyi félét olvastam és próbáltam ki, hogy fel sem tűnt, hogy amit beraktam az felesleges és rossz. Még jó, hogy van egy olyan rossz szokásom, hogy csak egy tesztszerveren kísérletezgetek először és hogy van, aki a hibáimat észreveszi :)
A 2-ben részben van igazad, mert az utolsó sor csak a tcp-t maszkolja, az udp-t nem és a DNS ott megy (ha jól tudom).

Nálam így van megcsinálva:

iptables -t nat -A POSTROUTING -o eth1.11 -s 10.0.0.0/8 -j domasq
iptables -t nat -A POSTROUTING -o eth1.11 -s 172.16.0.0/12 -j domasq
iptables -t nat -A POSTROUTING -o eth1.11 -s 192.168.0.0/16 -j domasq
iptables -t nat -A domasq -p tcp -j MASQUERADE --to-port 49500-65500
iptables -t nat -A domasq -p udp -j MASQUERADE --to-port 49500-65500
iptables -t nat -A domasq -j MASQUERADE

De miért nevezitek ezt "maszkolásnak"? (eddig még senkitől nem hallottam szerencsére)
Ez a fogalom mást jelent TCP/IP terminológia szerint (az angol "masking" magyar megfelelője), ezért baromi félrevezető, amikor két, jelentésében eltérő idegen szóhoz valaki ugyanazt a magyar megfelelőt akarja használni.

Jár a pont, a 2 részben az "általános" maszk valóban csak a tcp-t maszkolja, így csak részben igaz, amit mondtam. Itt én csúsztam el, csak nálam annyira alap, hogy a WAN felé *mindent* maszkolni kell, hogy átsiklottam afölött, hogy te itt is szűrsz és csak a tcp forgalmat maszkolod. Viszont ennek eredménye, hogy minden más, ami kimehet, az maszkolatlanul fog kisunnyogni, így viszont esélye nincs, hogy a válasz visszataláljon, ergo fölöslegesen terheli a kimenő sávszélességet. És hogy mi minden akadhat el emiatt? Igazából minden, ami nem tcp/ip. Pár példa, a teljesség igénye nélkül:
- udp csomagok - tehát ntp nem lesz, de openvpn-t se akarj csinálni udp alapokon!
- icmp sem fog gurulni, a ping tehát felejtős...
- egyéb protokolok pl. gre - gre tunel sem épülhet fel így, tehát pptp sem lesz...
- stb.

Megnéztem: ebben valóban van hasonló megoldás, mint nálad, azonban van egy nagyon fontos különbség, amely felett elsiklottál! Ebben a példában a squid nem a tűzfalon fut, cserébe viszont ugyanabban a subnetben van, amelynek a forgalmát transzparensen proxy-zni kell. Itt könnyű belátni, hogy ebben az esetben ha nincs turpisság a tűzfal szabályoknál, akkor a squid-ról kifelé induló lekérdezést is visszaverné a tűzfal magára a squid-ra, ami magas forgalmat ugyan generálna, de sikeres lekérdezést nem eredményezne. Éppen ezért itt az első szabály, hogy a squid gépről jövő egyébként jogos lekérdezéseket engedjük ki, azaz valóban ACCEPT target szerepel a feltétel eredményeként - de éppen ezért a feltétel nem is a teljes subnetre, sőt mindenre vonatkozik (mint nálad), hanem kizárólag a proxy gépre!
Mondjuk ettől a szabálysortól sem vagyok hasra esve, mert a második sor minden forgalmat, amelynek a célja a 80-as port, azt a squid felé továbbít. Tehát egy WAN lábra érkező kérést is... Ok, a FORWARD láncon megfogható, de:
- minek módosítsak olyan csomagot, amit később úgyis eldobok?
- az a FORWARD szabály, amely ezt a forgalmat tiltaná, a példában nem szerepel...
A harmadik szabály szintén nagyon fontos - de ez sem szimpatikus... A szerepe az, hogy a belső hálóból ha a forgalom át lett irányítva a külön gépen futó squid-hoz és ekkor a forrás IP cím nem kerül módosításra, akkor abból megint csak baj van, mert a squid amikor a választ küldené a kérésre, akkor azzal fog szembesülni, hogy a kérdező gép a helyi subnetben van, így a válasz csomagot direktben, a tűzfal kihagyásával tolja vissza. Csakhogy a kérdező masina eredetileg nem a squid gépet szólította meg, a tűzfal mahinációkról mit se tud - tehát nem a squidtól várja a választ. Amikor tehát a válasz direktben megérkezik, azt eldobja és ezzel itt meg is halt a dolog. Ezen segít a POSTROUTING-ban elhelyezett MASQUERADE: így a squid azt hiszi, hogy a lekérdezést a tűzfal követi el, így annak is válaszol - így viszont a tűzfal kapja meg a válasz csomagot, szépen visszaalakítja, visszaadja a kérdezőnek - és működik a rendszer. Csakhogy! Ehhez egy adott forgalmat kellene maszkolni, ez a szabály meg maszkol mindnet. Tehát ha ezen a tűzfalon pl. site2site vpn is terminálódik, akkor az így megint csak érdekes lesz, mert a túloldali site-on mindig csak az látszik, hogy innen csak a tűzfal dolgozik - hiszen minden site-on belüli gép VPN-be menő forgalma is maszkolódna ezen szabály alapján. A bónusz pedig a squid log: ugyanis ott ahhoz, hogy a forgalom mehessen, valóban szükséges ez a nat, de cserébe a squid is azt fogja látni, hogy egyetlen kliense van: a tűzfal. Innen kezdve a logból tehát az megmondható, hogy milyen URL lett lekérve - az nem, hogy melyik gépről. Transzparens proxy esetén pedig authentikáció nem játszik - tehát ebbe az irányba sem lehet mozdulni a jó cél érdekében...

volt szerencsém ilyen "nem a gateway-en fut a squid, de legyen transzparens" sztori összerakásához és a

Amikor tehát a válasz direktben megérkezik, azt eldobja és ezzel itt meg is halt a dolog.

problémánál én arrafele mentem el, hogy a GW szimplán routolta a fogralmat a squidbox felé, az pedig REDIRECT-tel elfogta, így amikor a választ küldte a user gépének, (mintegy NAT GW) a target IP-vel válaszolt: épp erre számított a user gép.

ez kevesebb plusz forgalmazással is jár.

annyi érdekesség van benne, hogy a linux GW ha ugyanarra az interface-re routol egy csomagot mint amin bejött, akkor küld egy ICMP redirect-et, amit érdemes net.ipv4.conf.*.send_redirects -cel kikapcsolni, nehogy a munkaállomás értelmezze és aztán összekavarja nekünk a dolgokat.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( render_elek v | 2016. 05. 13., p – 14:06 )

Hadd hozzam vissza egy kicsit a témát.
Eddig ott tartok (köszönet a hozzászólóknak), hogy most már, ha a böngészőben 3128-at írok a proxiba, akkor már nem tanusítványhibával, hanem rendes proxy access denied-al tilt.
Ha viszont nincs proxy, akkor jön a tanusítványhiba, de az apróbetűs részben rá lehet kattintani, hogy akkor is jelenjen meg a kívánt oldal, így hatástalan az egész.
Ezért ideiglenesen tűzfallal oldottam meg, hogy a "nincs proxy"-t bepippantóknak is tiltson.
El sem tudjátok képzelni, hogy mire elég a 4 Mbps 60 gépre, miután kiszűrtem a zuglyutyubozókat :)
A teljes megoldás az lenne, ha tűzfalbéli csomagdobálózás nélkül menne a tiltás, mert sajnos van olyan gép és idő, amikor engednem kell, és ezt squid-beli acl szabályokkal tudnám finoman szabályozni. De úgy látom, hogy miután 443 átugrott a 3130-ra és megtörtént a oda-vissza titkosítás, el is hagyja a squidot anélkül, hogy figyelembe venné az acl-eket.
Nem értem, hogy 3128-on miért megy és 3130-on miért nem.
A csatolt iptablesből a biztonsági cuccokat kiszedtem, hogy könnyebben olvasható legyen, ugyanígy a squid.confból a saját szabályokat.

iptables

# Generated by iptables-save v1.4.2 on Thu Apr 23 13:57:40 2009
*mangle
:PREROUTING ACCEPT [69:7668]
:INPUT ACCEPT [69:7668]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [48:7338]
:POSTROUTING ACCEPT [48:7338]
COMMIT

# Completed on Thu Apr 23 13:57:40 2009
# Generated by iptables-save v1.4.2 on Thu Apr 23 13:57:40 2009
*nat
:PREROUTING ACCEPT [15:1212]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [5:382]
-A PREROUTING -s 10.247.72.149 -p tcp --dport 443 -j ACCEPT
-A PREROUTING -s 10.247.72.149 -p tcp --dport 80 -j ACCEPT

-A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to-destination 10.247.72.149:3129
-A PREROUTING -i eth1 -p tcp --dport 443 -j DNAT --to-destination 10.247.72.149:3130

-A POSTROUTING -s 10.247.72.0/24 -o eth0 -j MASQUERADE
COMMIT

# Completed on Thu Apr 23 13:57:40 2009
# Generated by iptables-save v1.4.2 on Thu Apr 23 13:57:40 2009
*filter
# default policy: ami nem szabad, az tilos!!!
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
# Sajat lancok csomag es byte szamlaloinak kinullazasa
:fw_to_inet - [0:0]
:fw_to_lnet - [0:0]
:inet_to_fw - [0:0]
:inet_to_lnet - [0:0]
:lnet_to_fw - [0:0]
:lnet_to_inet - [0:0]
:security - [0:0]
# Hurok mehet
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

# IP hamisitas kiszurese loopra
-A INPUT -s 127.0.0.1/8 ! -i lo -j DROP

# Sajat lancok forgalom iranya alapjan
-A INPUT -i eth0 -j inet_to_fw
-A INPUT -s 10.247.72.0/24 -i eth1 -j lnet_to_fw
-A FORWARD -d 10.247.72.0/24 -i eth0 -o eth1 -j inet_to_lnet
-A FORWARD -s 10.247.72.0/24 -i eth1 -o eth0 -j lnet_to_inet
-A OUTPUT -o eth0 -j fw_to_inet
-A OUTPUT -d 10.247.72.0/24 -o eth1 -j fw_to_lnet

# csak a tuzfalon keresztul mehet a fw-olas (-d párja) lentebb
-A FORWARD -s 10.247.72.149 -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# pinghez
-A FORWARD -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# 1) Tuzfalrol kifele minden mehet
-A fw_to_inet -j ACCEPT
# 2) Tuzfalrol a helyire minden mehet
-A fw_to_lnet -j ACCEPT
# 3) Kintrol tuzfalra
# 3,a Veszelyes helyek alapbol tiltva

# Ez mind a youtubhoz
-A inet_to_fw -s 74.125.8.0/24 -j DROP
-A inet_to_fw -s 173.194.157.49/24 -j DROP
-A inet_to_fw -s 195.111.111.76/24 -j DROP
-A inet_to_fw -s 199.223.232.0/20 -j DROP
-A inet_to_fw -s 207.223.160.0/20 -j DROP
-A inet_to_fw -s 208.65.152.0/24 -j DROP
-A inet_to_fw -s 208.65.153.0/24 -j DROP
-A inet_to_fw -s 208.65.154.0/24 -j DROP
-A inet_to_fw -s 208.65.155.0/24 -j DROP
-A inet_to_fw -s 208.117.224.0/19 -j DROP
-A inet_to_fw -s 209.85.128.0/17 -j DROP
-A inet_to_fw -s 209.85.226.207/24 -j DROP
-A inet_to_fw -s 216.58.192.0/20 -j DROP
-A inet_to_fw -s 216.239.32.0/19 -j DROP

# 3,b IP-spoof forrascim hamisitott csomagok naplozasa-eldobasa
# 3,c DoS (Denial of service) es DistributedDoS-hoz SYN-Flood
# 3,d nmap detektalasa
# 3,e Portscan PoD
# 3,f Kozvetett DoS nem helyes TCP SYN, hanem helyette SYN/ACT
# 3,g Valasz- es a mar felepult kapcsolathoz tartozo csomag elengedese
-A inet_to_fw -m state --state RELATED,ESTABLISHED -j ACCEPT

# 4) Kintrol helyi halora
# 4,a Veszelyes helyek alapbol tiltva

# Ez mind a youtubhoz
-A inet_to_lnet -s 74.125.8.0/24 -j DROP
-A inet_to_lnet -s 173.194.157.49/24 -j DROP
-A inet_to_lnet -s 195.111.111.76/24 -j DROP
-A inet_to_lnet -s 199.223.232.0/20 -j DROP
-A inet_to_lnet -s 207.223.160.0/20 -j DROP
-A inet_to_lnet -s 208.65.152.0/24 -j DROP
-A inet_to_lnet -s 208.65.153.0/24 -j DROP
-A inet_to_lnet -s 208.65.154.0/24 -j DROP
-A inet_to_lnet -s 208.65.155.0/24 -j DROP
-A inet_to_lnet -s 208.117.224.0/19 -j DROP
-A inet_to_lnet -s 209.85.128.0/17 -j DROP
-A inet_to_lnet -s 209.85.226.207/24 -j DROP
-A inet_to_lnet -s 216.58.192.0/20 -j DROP
-A inet_to_lnet -s 216.239.32.0/19 -j DROP

# 4,b IP-spoof forrascim hamisitott csomagok naplozasa-eldobasa
# 4,c DoS (Denial of service) es DistributedDoS-hoz SYN-Flood vedelem
# 4,d nmap detektalasa
# 4,e Portscan PoD
# 4,f Kozvetett DoS nem helyes TCP SYN, hanem helyette SYN/ACT
# 4,g Valasz- es a mar felepult kapcsolathoz tartozo csomag elengedese
-A inet_to_lnet -m state --state RELATED,ESTABLISHED -j ACCEPT

# 5) Helyi halorol a tuzfalra minden mehet
-A lnet_to_fw -j ACCEPT
# 6) Helyi halorol kifele is minden mehet
-A FORWARD -d 10.247.72.149 -j ACCEPT
COMMIT
# Completed on Thu Apr 23 13:57:40 2009

squid

# itt vannak saját acl-ek (gépek, idősávok)

acl facebook dstdomain "/tiltott/noface.txt"
acl youtube dstdomain "/tiltott/noyoutube.txt"

# itt vannak a kivételek http_access -el elengedve

# -----------------------tiltás------------------------
http_access deny facebook
http_access deny youtube
# ----------------------Saját tiltás vége--------------

# aki eddig eljut, az már (elvileg) nem youtubozik

url_rewrite_program /usr/bin/squidGuard
http_access allow all

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
# http_access deny all

http_port 3128 ssl-bump cert=/etc/squid3/ssl_cert/minevunk.hu.pem key=/etc/squid3/ssl_cert/private/minevunk.hu.pem
http_port 3129 intercept
https_port 3130 intercept ssl-bump cert=/etc/squid3/ssl_cert/minevunk.hu.pem key=/etc/squid3/ssl_cert/private/minevunk.hu.pem

acl bump_sites dstdomain www.youtube.com .youtube.com.mx .facebook.com .hu-hu.mx
ssl_bump none localhost

ssl_bump server-first bump_sites
ssl_bump none all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER

always_direct allow all

cache_mem 2048 MB
cache_dir ufs /squid/cache 20480 16 256
access_log daemon:/var/log/squid3/access.log squid
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 . 0 20% 4320