Sajnos felmerült az igény a cégünknél ,hogy lenne pár ember akiknél engedélyezni kellene a facebook, twitter, stb-t, így nem tudom a dns-ből tiltani, csakis a proxy szerverről megoldható. Bármelyik más http oldalat tudok blokkolni, illetve a kivétel IP-re tudom engedélyezni, de a https oldalakat nem tudom megfogni. A tűzfal másik gépen van, ezért nem tudok rákérni egy whois-t a domain-ra, és nem is szeretném rárakni.
squid 3.3.8
squid.conf
http_port XX.XX.XX.XX:3128
visible_hostname proxy2.cegem.hu
dns_nameservers 10.XX.XX.XX
#eset gateway beállítása
icap_enable on
icap_send_client_ip on
icap_send_client_username on
icap_client_username_header X-Client-Username
icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1355/av_scan
icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1355/av_scan
adaptation_access service_req allow all
adaptation_access service_resp allow all
acl belso src 10.XX.XX.0/23
acl belso src 10.XX.XX.0/23 #belso
acl kivetel src "/etc/squid3/kivetel"
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
#block list
acl block dstdomain "/etc/squid3/block"
deny_info http://webserver.cegem.hu/hiba/hiba.html block
acl ipblock src "/etc/squid3/ipblock"
http_access deny !Safe_ports
http_access allow block kivetel
http_access deny block belso
http_access allow belso
http_access deny all
Segítségeteket előre is köszönöm.
------------
Megoldás:
update: ubuntu 14.04 squid- 3.3.8 ssl bekapcsolás:
http://docs.diladele.com/administrator_guide_4_0/system_configuration/h…
sudo apt-get install devscripts build-essential fakeroot libssl-dev
mkdir squid && cd squid
sudo apt-get source squid3
sudo apt-get build-dep squid3
sudo dpkg-source -x squid3_3.3.8-1ubuntu6.3.dsc
sudo nano squid3-3.3.8/debian/rules
beleírni:
--enable-ssl \
--enable-ssl-crtd
sudo nano squid3-3.3.8/src/ssl/gadgets.cc
static int extensions[]= {
//NID_key_usage,
cd squid3-3.3.8 && dpkg-buildpackage -rfakeroot -b
squid fordítása /ssl bekapcsolása:
sudo service squid3 stop
sudo apt-get install ssl-cert
sudo dpkg --install squid3-common_3.3.8-1ubuntu6.3_all.deb
sudo dpkg --install squid3_3.3.8-1ubuntu6.3_amd64.deb
sudo dpkg --install squidclient_3.3.8-1ubuntu6.3_amd64.deb
sudo ln -s /usr/lib/squid3/ssl_crtd /bin/ssl_crtd
sudo /bin/ssl_crtd -c -s /var/spool/squid3_ssldb
sudo chown -R proxy:proxy /var/spool/squid3_ssldb
sudo service squid3 restart
sudo squid3 -v |grep ssl elvileg be le kapcsolva
squid.conf:
http_port 10.XX.XX.XXX:3128 ssl-bump dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl/proxy2.cegem.hu.crt key=/etc/squid3/ssl/proxy2.cegem.hu.key
sslcrtd_program /usr/lib/squid3/ssl_crtd -s /var/spool/squid3_ssldb -M 4MB
visible_hostname proxy2.cegem.hu
dns_nameservers 10.XX.XX.XX
#eset gateway beállítása
icap_enable on
icap_preview_enable on
icap_persistent_connections on
adaptation_send_client_ip on
icap_send_client_ip on
icap_send_client_username on
icap_client_username_header X-Client-Username
icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1355/av_scan
icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1355/av_scan
adaptation_access service_req allow all
adaptation_access service_resp allow all
forward_max_tries 25
shutdown_lifetime 3 seconds
acl belso src 10.XX.XX.0/23
acl belso src 10.XX.XX.0/23
acl kivetel src "/etc/squid3/kivetel"
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 SSL method CONNECT
acl CONNECT method CONNECT
#block list
acl block dstdomain "/etc/squid3/block"
deny_info http://webserver.cegem.hu/hiba/hiba.html block
http_access deny !Safe_ports
http_access deny CONNECT !SSL_Ports
http_access allow block kivetel
http_access deny block
http_access allow belso
http_access deny all
- 5705 megtekintés
Hozzászólások
törölve
- A hozzászóláshoz be kell jelentkezni
Légy szíves, ezt NE.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Remélem, hogy a rajzos formával volt a gond, és nem az általa sugallt véleménnyel :).
- A hozzászóláshoz be kell jelentkezni
kb nekem is :)
A fönököm amikor kitaláltja egy feladatot akkor csak azt mondja, hogy oldjam meg és persze ne kelljen fizetni érte...
- A hozzászóláshoz be kell jelentkezni
Nekem ilyen van:
Tiltás:
acl to_rule3 dstdomain "tilt.acl"
http_access deny to_rule3 within_timeframe_rule3 for_auth_rule3
http_reply_access deny to_rule3 within_timeframe_rule3 for_auth_rule3
Engedélyezés:
acl to_rule2 dstdomain "enged.acl"
http_access allow to_rule2 within_timeframe_rule2
http_reply_access allow to_rule2 within_timeframe_rule2
tilt.acl:
.mindenaldomain.hu
csak.ezagepnev.hu
enged.acl:
.facebook.com
.estarsai.hu
Cirka ezek mennek, de sokkal jobban jársz, ha alapból tiltasz mindent, és fehérlista alapján engedélyezel. Az elején sok vele a meló, és sokat is fognak a userek szívni, de amikor beáll, akkor onnantól nyugi van.
fejesjocó: amiről nem tudsz, az nem biztos, hogy nincs.
--
PtY - www.onlinedemo.hu, www.westeros.hu
- A hozzászóláshoz be kell jelentkezni
Ha jól értem bizonyos domainek elérését akarod tiltani.
dstdom_regex
acl aclname dstdom_regex [-n] [-i] \.foo\.com
- A hozzászóláshoz be kell jelentkezni
A https-nél a teljes forgalom titkosított kapcsolaton keresztül megy a kliens és a szerver között, és ebbe a proxy nem lát bele. Ezért nem tudsz url alapján szűrni, mert nem látod az url-t.
Ehhez az kell, hogy a proxy beépüljön a kommunikációba ("man in the middle"), vagyis hogy a kliensek https kérései nála végződjenek, és a proxy kapcsolódjon egy másik https kapcsolattal a valódi server-hez.
A squid elvileg tud ilyet, ha úgy van fordítva
http://wiki.squid-cache.org/Features/HTTPS
- A hozzászóláshoz be kell jelentkezni
Az új SNI funkcióval már egészen használható is, de azért a MIM proxyt érdemes rendes proxyként futtatni.
- A hozzászóláshoz be kell jelentkezni
El is hasal a hsts és a pkp miatt :)
--
PtY - www.onlinedemo.hu, www.westeros.hu
- A hozzászóláshoz be kell jelentkezni
Fel kell vedd user CA-nak a squid mestercertjét, mert user ca általában felülírhatja a HSTS-t. (Firefoxban biztosan)
- A hozzászóláshoz be kell jelentkezni
Nekem akkor se ment.
Fedora 22, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Az IMHO csak arra elég, hogy ne sírjon a böngésző.
--
PtY - www.onlinedemo.hu, www.westeros.hu
- A hozzászóláshoz be kell jelentkezni
Egy vállalati környezetben egészen biztosan nem okoz gondot az SSL MIM. Tudom, mert használtuk. Az STS mit sem ér ilyenkor, a PKP-t pedig egy megfelelően beállított vállalati mestercert felülírja a klienseken.
Az egyetlen probléma ~1 éve az volt hogy a squid nem továbbította az SNI-t ezért az SNI-t kihasználó szerverek nem mindig a jó certet küldték. Azóta ez a feature bekerült a squidbe a dokumentáció szerint, de tesztelni nekem még nem volt alkalmam.
- A hozzászóláshoz be kell jelentkezni
Nem a vállalati környezetben probléma, hanem aa külső weboldalak működésében okoz hat gondot ilyen esetekben a MITM.
Van egy 3 éve telepített squid-et használó rendszerem, sincs baja az SNI-vel (2.6.STABLE22 - amiből a STABLE23 a lagújabb, és az 17 Sep 2009, így az a ~1 év elég furának tűnik).
--
PtY - www.onlinedemo.hu, www.westeros.hu
- A hozzászóláshoz be kell jelentkezni
Én csináltam ilyet, viszont a HSTS miatt sajnos sok weboldal már nem fog menni. Legalábbis nem tudtam vele mit kezdeni.
Fedora 22, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
A forgalomba nem, de a CONNECT requestben azért van infó.
- A hozzászóláshoz be kell jelentkezni
wtf ?
Lemaradtam valamiről, vagy a HTTPS:// beírása bármilyen böngészőbe azt eredményezi, hogy már azonnal titkosítottan küldi el a címet is....
Nah, szóval akkor lehet URL alapján szűrni, vagy sem? :p
- A hozzászóláshoz be kell jelentkezni
Az URL titkosítva utazik csak. A domain-t viszont https esetén is elküldi titkosítatlanul is a böngésző. Ezt hívják SNI-nek, és arra (is) használják hogy egy IP címre csatlakozva több különböző cert közül a megfelelőt küldje a server.
- A hozzászóláshoz be kell jelentkezni
openssl s_connect -client sni.kepes.host:443 -servername sni.kepes.host
Szóval lehet, hogy lemaradtál valamiről :)
--
PtY - www.onlinedemo.hu, www.westeros.hu
- A hozzászóláshoz be kell jelentkezni
Hm thx. :) valóban lemaradtam :)
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
Tűzfalon MAC address alapján iptablesben engeded nekik (https-t a squid úgysem tud), többinek meg tiltod. Problem solved. :)
- A hozzászóláshoz be kell jelentkezni
Tudna https-t (CONNECT tunnel).
- A hozzászóláshoz be kell jelentkezni
Mindíg tanul az ember, köszi. :)
- A hozzászóláshoz be kell jelentkezni
Tud. Csak a forgalomba nem lát bele. A kérésbe simán belelát, domain-t/gépnevet lehet tiltani. Tartalmat nem. Azt csak man in the middle-lel lehet, de a fejlettebb ssl technológiákat használó oldalak így meg nem fognak működni.
--
PtY - www.onlinedemo.hu, www.westeros.hu
- A hozzászóláshoz be kell jelentkezni
Mindenkinek köszönöm a segítséget, megoldást az update rész után írtam, a blockolás megy, bármely https oldalt tudom mostmár blokkolni, egy kis teszt és utána mehet ki élesbe.
Sajnos egy 300+ gépparkú cégnél manuálisan felvinni az engedélyezett oldalakat hát öö egy kicsit kemény munka lett volna :) illetve kitört volna a palotaforradalom és az őrség sem bírta volna.
- A hozzászóláshoz be kell jelentkezni
Mondjuk aki ügyes, az megoldja, mert webproxy oldalakon keresztül bejelentkezik (tapasztalat). És vígan használja.
300+ kliens van itt is, de itt fordítva volt a kérés, előző körben jött az hogy senkinek semmi facebook* . Jó. DNSből megoldottuk. Mivel mindenki helyi DNS szerverrel dolgozik, új zóna facebook.com -ra felvéve, átirányítva belső intranet portálra. Hello.
Aztán jött a kérés, hogy úú. hát bizonyos helyeken kellene a facebook... Azt már nem részletezném hogy hogyan sikerült átmenni a saját tiltásunkon :)
- A hozzászóláshoz be kell jelentkezni
Bizonyos helyeken külső NS-t konfigoltál be. Vagy esetleg BIND9 split-brain config.
- A hozzászóláshoz be kell jelentkezni
Aki meg ügyes admin, az letiltja a saját proxy-ján a proxy connect továbbítását, és nem tudnak külső proxy-t használni a userek.
A böngészők proxybeállításainak piszkálását szintén.
A DNS-sel már könnyebben lehet trükközni.
--
PtY - www.onlinedemo.hu, www.westeros.hu
- A hozzászóláshoz be kell jelentkezni
btw a megoldás egy másik NS felhúzása volt.
A kliens oldali trükközés itt nem játszik, mert a firewall policy gyakorlatilag semmit nem enged ki a belső hálóról (se DNS lekérést, de még egy szimpla időszinkront se) :)
Szóval hiába játssza át a proxyt, a tűzfalon fennakad.
Szal fel lett húzva egy second NS, amiben nem volt fb zona. Adott gépeken beállítva az.
- A hozzászóláshoz be kell jelentkezni
az ehhez hasonló oldalakkal mit lehet tenni? - Mert nem fogja érdekelni a biztonsági figyelmeztetés, hogy a 3. fél mit fog kezdeni az adatokkal...
http://www.webproxy.hu/
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni