On 24/07/2013 12:35 a.m., kannan rbk wrote:
> Hi ,
>
> Thank you for your precious time.
>
> We are using squid version 3.1.10 version. Our requirement is
> https://xyz.abc.com/gadgets should allow but same "abc.com" domain
> other then any request should block. This setup testing via ssl_bump,
> but it doesn't work for me. Please help me on this.
>
> Configuration file is below.
>
>
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32 ::1
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
> acl allowurls url_regex [-i] \.gadgets$
Problem #1: When testing the URL-path it is better to use urlpath_regex
which prevents any problems matching in the domain and username portions
of the URL. And also gives Squid a chance to detect and warn about
incorrect usage of the ACL.
The problem with urlpath_regex on HTTPS traffic is that the path
_does not exist_ in CONNECT requests. Using url_regex instead of
urlpath_regex to test the path portion will have no better luck finding it.
Problem #2: you are using "[-i]" in the ACL definition. That exists in
the documentation to signify that the "-i" is an optional flag. If you
want the regex to be case insensitive, add the -i (without brackets).
Otherwise for case sensitive regex omit it entirely.
The result of your leaving the [] brackets in is that the ACL matches
any URL containing a "-" OR an "i" *anywhere* in the URL. This has some
important side effects later...
Problem #3: your pattern begins \. which means you are searching for
the text ".gadgets" at the end of the URL, which can never match
"/gadgets" at the start of the URL path segment.
Fix: I think you need to use this instead:
acl allowurls urlpath_regex -i /gadgets$
> acl blkdomain dstdomain .abc.com
>
> # Example rule allowing access from your local networks.
> # Adapt to list your (internal) IP networks from where browsing
> # should be allowed
> acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
> acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
> acl localnet src fc00::/7 # RFC 4193 local private network range
> acl localnet src fe80::/10 # RFC 4291 link-local (directly
> plugged) machines
>
> 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
>
> #
> # Recommended minimum Access Permission configuration:
> http_port 3129 ssl-bump cert=/etc/squid/test.crt key=/etc/squid/test.key
> ssl_bump deny blkdomain
> ssl_bump allow allowurls
Problem #4: ssl_bump ACLs are run on the CONNECT request details before
bumping to determine whether bumping can take place. The allowurls at
that point never has access to the URL-path details, so only the [-i]
regex pattern error will ever match anything.
Fix: it looks like you can remove this line form your config file
entirely. The next ssl_bump line to match anything is an "ssl_bump allow
all".
> http_access allow allowurls
Problem #5, (side effect of #2). Since any URL with "-" or "i" in it
anywhere will match this ACL, this rule being here above the default
security protections will allow *anyone* completely free open access to
send requests through your proxy. That includes arbitrary CONNECT
requests to any domain with a hypen (ie spammers domain
"open-proxy.example.com:25").
Fix: This will not be so bad once you fix problem #2, but please
consider moving this line down below the default security settings
anyway. They are there to protect you from this type of ACL mistake
amongst other things.
> # Only allow cachemgr access from localhost
> http_access allow manager localhost
> http_access deny manager
> #http_access allow allowurls
> # Deny requests to certain unsafe ports
> http_access deny !Safe_ports
>
> # Deny CONNECT to other than secure SSL ports
> http_access deny CONNECT !SSL_ports
>
> # We strongly recommend the following be uncommented to protect innocent
> # web applications running on the proxy server who think the only
> # one who can access services on "localhost" is a local user
> #http_access deny to_localhost
>
> #
> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> #
>
> # Example rule allowing access from your local networks.
> # Adapt localnet in the ACL section to list your (internal) IP networks
> # from where browsing should be allowed
>
> http_access allow accounts
> http_access allow localnet
> http_access allow CONNECT
Problem #6: Anyone on your network can send *anything* through your
Squid. Even if they are not matching the accounts or localnet ACLs.
Fix: Remove this line. The default security rule we ship with Squid
about CONNECT does permit traffic through port-443 or other ports at
your discretion.
> #http_access allow localhost
>
>
> http_port 3129 ssl-bump cert=/etc/squid/test.crt key=/etc/squid/test.key
> ssl_bump allow allowurls
> # Squid normally listens to port 3128
> #ssl_bump allow all
> #ssl_bump deny allowurls
> #ssl_bump deny localhost
> ssl_bump deny blkdomain
Problem #7: you already had all the above rules up higher in your config
file. You can expect a WARNING or ERROR from Squid about the dulicate
port 3129 entry. The access controls will be ignored or never match
anything if they ever get tested.
Fix: Please remove the duplicate access lines. You will want to consider
removing the many commented-out lines as well. It will all make your
config a lot clearer to read and understand.
> #ssl_bump deny all
> ssl_bump allow all
> http_access deny all
>
> always_direct allow all
>
>
> # And finally deny all other access to this proxy
>
> sslproxy_cert_error allow all
> #We recommend you to use at least the following line.
> hierarchy_stoplist cgi-bin ?
NOTE: that recommmendation was an oversight. You should remove that
hierarchy_stoplist line to make always_direct work a little better.
Amos
> # Uncomment and adjust the following to add a disk cache directory.
> #cache_dir ufs /var/spool/squid 100 16 256
>
> # Leave coredumps in the first cache dir
> coredump_dir /var/spool/squid
>
> # Add any of your own refresh_pattern entries above these.
> 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
>
>
> logformat squid %ts.%03tu %6tr %>a %>A %Ss/%03>Hs %<st %rm %ru %un %Sh/%<A %mt
> cache_log /var/log/squid/cache.log
> access_log /var/log/squid/access.log
>
> Regards ,
> Bharathikannan R
>
> On Sun, Jul 7, 2013 at 12:20 PM, kannan rbk <kannanrbk.r_at_gmail.com> wrote:
>> Dear Team,
>>
>> I am using squid proxy(3.1). Read some articles and blogs , they said
>> squid cannot support "urlpath_regex , url_regex" because of https
>> connections are encrypted. Is there any alternative for this?
>>
>> How can I block https request based on urls from our network?
>>
>> I want to allow "zmedia.com/shop" through SSL.
>>
>> --
>> Regards,
>>
>> Bharathikannan R
>
>
Received on Wed Jul 24 2013 - 01:52:13 MDT
This archive was generated by hypermail 2.2.0 : Wed Jul 24 2013 - 12:00:43 MDT