On 16/12/2015 1:03 p.m., Amaury Viera Hernández wrote: > Hello everyone. This is a more detailed explanation about my > trouble: > The more detailed explanation makes it clear that you are not going to be able to use the login=PASSTHRU workaround for getting NTLM to work. Clients that are intercepted simply *cannot* authenticate to a proxy. So there is nothing to pass through. That leaves you with Negotiate or Basic authentication credentials explicitly added by your proxy. Be aware that doing what you intend will make you and your student account personaly responsible for *all* traffic that goes through your proxy to the upstream. If anyone else manages to hook into your wifi AP, they will essentially have free access and you pay the costs. <snip> > > I'm using ubuntu 15.10 with squid3 (3.3.8) > > I have this configuration in squid.conf (This is very functional for > local domain(without proxy authentications, against the local > domains, for example: intranet.uci.cu, but for internet domains I > need to authenticate(cache_peer my proxy with the proxy of my > university)) ) > 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 > acl localdst dstdomain > acl mi_red src 10.42.0.0/24 > http_access allow mi_red So anyone connecting from 10.42.0.0/24 is allowed through this proxy. With absolutely zero protections. That is bad. At the very least move the "allow mi_red" line down ... > http_access deny !Safe_ports > http_access deny CONNECT !SSL_ports > http_access allow localhost manager > http_access deny manager ... to here. > http_access allow localhost > http_access deny all > http_port 10.42.0.1:3128 transparent 3128 is the registered Squid port for foward/explicit-proxy communications. It should remain in squid.conf but without the "transparent" mode flag. You should probably also set this port to be "127.0.0.1:3128" for yoru situation. You should pick another port number randomly for the intercept and use that for "intercept" mode traffic. There are also additional parts to the firewall script, which I will cover below. Also, notice that NAT port is "intercept" not "transparent". Please run "squid -k parse" and fix any warnings it produces about other things. I'm only mentioing the big ones which that old version might not be able to mention. > 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 > cache_mem 512 MB > cache_dir ufs /var/spool/squid3 2048 16 256 > cache_effective_user proxy > cache_effective_group proxy > half_closed_clients off > maximum_object_size 1024 KB > cache_swap_low 90 > cache_swap_high 95 > memory_pools off > error_directory /usr/share/squid3/errors/es/ > access_log /var/log/squid3/access.log squid This ... > cache_peer 10.0.0.1 parent 8080 0 no-query default no-digest login=avhernandez:MyPass > never_direct allow all ... is correct for sending Basic auth credentials to the upstream. That may work, but is not very secure. Your Squid should also be capable of the login=NEGOTIATE method of authentication. If that works with the upstream proxy (it may or may not) then it is better to use than Basic. First do the firewall fixes below before experimenting with these changes though. > > I'm using this firewall script > Best practice is to use the iptables-restore tool when scripting firewall actions. Otherwise there are gaps in timing between the -F flush command and rule setup during which any active traffic can slip past your intended rules and have long-lasting effects on the connection states. IIRC it was setup the firewall manually with your rules, and use the restore tool to save a config snapshot for fast loading by the script. > #!/bin/sh > # IP del servidor SQUID > SQUID_SERVER="10.42.0.1" > # Interface conectada a Internet > INTERNET="enp4s0" > # Interface interna > LAN_IN="wlp2s0" > # Puerto Squid > SQUID_PORT="3128" Change that to whatever you use in squid.conf for the intercept port. > > # Limpia las reglas anteriores > iptables -F > iptables -X > iptables -t nat -F > iptables -t nat -X > iptables -t mangle -F > iptables -t mangle -X > # Carga los modulos IPTABLES para NAT e IP con soporte conntrack > modprobe ip_conntrack > modprobe ip_conntrack_ftp > echo 1 > /proc/sys/net/ipv4/ip_forward > # Politica de filtro por defecto > iptables -P INPUT DROP > iptables -P OUTPUT ACCEPT > # Acceso ilimitado a loop back > iptables -A INPUT -i lo -j ACCEPT > iptables -A OUTPUT -o lo -j ACCEPT ICMP is a mandatory protocol, and needs to be allowed as well. - When bad traffic is rejected by your machine it is ICMP packets that do the rejection. - When something is not quite working right it is ICMP error messages which allow software like Squid to automatically repair or workaround the damage. And to help you debug what is going on if manual attention is needed. > # Permite UDP, DNS y FTP pasivo > iptables -A INPUT -i $INTERNET -m state --state ESTABLISHED,RELATED -j ACCEPT The comment about "UDP, DNS y FTP pasivo" is does not match the rule it is documenting. The rule is allowing aready established connections from remote / Internet clients to the servers running on your machine to fast-track through the firewall. That is normal and okay as a rule. The issue I am highlighting here is that the comment is bad and may be making you think wrong. You also need this rule to apply to all traffic, on all interfaces (including "lo"). So remove the -i parameter. This... > # Establece el servidor como router para la red > iptables --table nat --append POSTROUTING --out-interface $INTERNET -j MASQUERADE > iptables --append FORWARD --in-interface $LAN_IN -j ACCEPT ... No. Remove. There is a better MASQUERADE rule in the wiki page referenced below. If you need to allow any traffic forwarding straight through your machine. Do so only and specifically for individual ports or protocols. You are not running a carrier network here. For example; this is where you set DNS queries to be allowed: -t FORWARD -p udp --dport 53 -j ACCEPT -t FORWARD -p tcp --dport 53 -j ACCEPT Given the phone involvement you may also want to look into whether it wants VoIP ports. And email POP/IMAP/SMTP/Submit ports may also be needed - be extra careful about random hijackers sending Spam on those ones though. > # acceso ilimiato a la LAN > iptables -A INPUT -i $LAN_IN -j ACCEPT That above one lets unconditionally all remote devices that can connect to your wifi interface use any service on your machine. Which is bad. Especially since you also unconditionally allow access through the proxy in squid.conf. If you need any rules on INPUT at all, you should make them specific to the services you want to be available publicly. But remember that these rules are for accessing services running directly on your machine - not relevant when connecting to upstream or Internet servers. Both INPUT and FORWARD are the main firewall protections against traffic being sent into your machines software, or trying to forward through it to other machines. Be very careful what you ACCEPT in those table rules. > iptables -A OUTPUT -o $LAN_IN -j ACCEPT This... > # Redirige las peticiones de la red interna hacia el proxy > iptables -t nat -A PREROUTING -i $LAN_IN -p tcp --dport 80 -j DNAT --to $SQUID_SERVER:$SQUID_PORT > # Redirige la entrada al proxy > iptables -t nat -A PREROUTING -i $INTERNET -p tcp --dport 80 -j REDIRECT --to-port $SQUID_PORT ... No. Remove. For Squid use the rules on this wiki page (in the same order as shown), instead of both sets above which I marked as "No. Remove". <http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat> PS. Also dont forget that IPv6 exists. Your firewall settings *need* to also correctly setup IPv6 access (or denial) with ip6tables. Since you are working with a phone it is even more likely that IPv6 will be needed than on a generic LAN / wifi. They should generally match your IPv4 settings. But there are some small differences. HTH Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
