Explicitly use direct client IP in acl

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Explicitly use direct client IP in acl

Orion Poplawski
Hello -

   We're using a setup like this:

client -> e2guardian -> squid -> internet

e2guardian is providing filtering and SSL inspection.  Currently we only
allow access to e2guardian from our internal network.  Currently we
enforce access to squid come from localhost, except for some specific
sites which do not work with SSL inspection.

Then we allow:

client -> squid -> internet

this is based on the (non-forwarded) client IP.

We would like to open up access to e2g from the internet but require
authentication in that case.  This would require the use of forwarded
IPs so the squid could distinguish between them (e2g does not do auth
directly - it lets squid handle that).  But then this breaks our config
above because we no longer can distinguish between connections from e2g
and direct ones.

Is there any way in an acl to explicitly request the "direct" (i.e.
non-indirect) IP address?  This would allow use to use one type for some
acls and the other for other acls.  This doesn't seem possible from what
I can see.

I'm guessing we'll need to implement a separate proxy configuration for
external access, but I'd like to avoid it if possible.

Thanks,
   Orion

--
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       [hidden email]
Boulder, CO 80301                 https://www.nwra.com/


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Explicitly use direct client IP in acl

Amos Jeffries
Administrator
On 10/07/20 9:54 am, Orion Poplawski wrote:

> Hello -
>
>   We're using a setup like this:
>
> client -> e2guardian -> squid -> internet
>
> e2guardian is providing filtering and SSL inspection.  Currently we only
> allow access to e2guardian from our internal network.  Currently we
> enforce access to squid come from localhost, except for some specific
> sites which do not work with SSL inspection.
>
> Then we allow:
>
> client -> squid -> internet
>
> this is based on the (non-forwarded) client IP.
>
> We would like to open up access to e2g from the internet but require
> authentication in that case.

Okay.

>  This would require the use of forwarded
> IPs so the squid could distinguish between them (e2g does not do auth
> directly - it lets squid handle that).  But then this breaks our config
> above because we no longer can distinguish between connections from e2g
> and direct ones.


How do you come to that conclusion?

What is your Squid version?

What is your current squid.conf contents?


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Explicitly use direct client IP in acl

Orion Poplawski
On 7/9/20 6:50 PM, Amos Jeffries wrote:

> On 10/07/20 9:54 am, Orion Poplawski wrote:
>> Hello -
>>
>>    We're using a setup like this:
>>
>> client -> e2guardian -> squid -> internet
>>
>> e2guardian is providing filtering and SSL inspection.  Currently we only
>> allow access to e2guardian from our internal network.  Currently we
>> enforce access to squid come from localhost, except for some specific
>> sites which do not work with SSL inspection.
>>
>> Then we allow:
>>
>> client -> squid -> internet
>>
>> this is based on the (non-forwarded) client IP.
>>
>> We would like to open up access to e2g from the internet but require
>> authentication in that case.
>
> Okay.
>
>>    This would require the use of forwarded
>> IPs so the squid could distinguish between them (e2g does not do auth
>> directly - it lets squid handle that).  But then this breaks our config
>> above because we no longer can distinguish between connections from e2g
>> and direct ones.
>
>
> How do you come to that conclusion?
I don't know how to distinguish between connections that go through e2g
and connections that do not.  Currently anything with a client IP of
localhost has gone through e2g.  Anything with a different client IP has
not.  If I use the X-Forwarded-As IP to distinguish between internal and
external (for auth purposes) I no longer know how to distinguish between
forwarded connections and non-forwarded connections.  Is there a
forwarded flag that can be used as an acl?  I couldn't see anything in
the acl docs.

> What is your Squid version?

3.5.20 (EL7), though I may be able to update 4.4 (EL8).

> What is your current squid.conf contents?

This part of our ansible template.  Essentially we have a list of hosts
in "Allowed_SSL_Hosts" and "Allowed_HTTP_Hosts: that we allow any client
to connect directly through squid to (via HTTPS/HTTP respectively).

acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

acl SSL_ports port 443
acl SSL_Ports port 563          # smtps
acl SSL_Ports port 5228         # mtalk.google.com
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl CONNECT method CONNECT

acl Allowed_SSL_Hosts ssl::server_name {{ ansible_nodename }}

# We can't MITM these, but allow them through the proxy
{% for domain in allowed_ssl_hosts %}
acl Allowed_SSL_Hosts ssl::server_name {{ domain }}
{% endfor %}
# Some hosts present problems for e2guardian for unknown reasons
{% for domain in allowed_http_hosts %}
acl Allowed_HTTP_Hosts dstdomain {{ domain }}
{% endfor %}

# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# macOS Catalina is using CONNECT to gs.apple.com:80
http_access allow localnet Allowed_HTTP_Hosts

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

# 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

# All traffic should be coming via e2guardian on localhost
http_access allow localhost

# Allow certain sites to be connected to directly
http_access allow CONNECT localnet Allowed_SSL_Hosts

# Allow some users/applications to connect from outside
auth_param digest realm "NWRA Proxy"
auth_param digest program /usr/lib64/squid/digest_file_auth
/etc/squid/passwd
# freshclam only supports basic auth -
https://bugzilla.clamav.net/show_bug.cgi?id=12468
auth_param basic realm "NWRA Proxy"
auth_param basic program /usr/lib64/squid/basic_ncsa_auth
/etc/squid/htpasswd
acl authenticated_users proxy_auth REQUIRED
http_access allow CONNECT authenticated_users Allowed_SSL_Hosts
# freshclam 0.101.5 uses HTTP
http_access allow authenticated_users Allowed_HTTP_Hosts

# And finally deny all other access to this proxy
http_access deny all

Thank you,

   Orion

--
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       [hidden email]
Boulder, CO 80301                 https://www.nwra.com/


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Explicitly use direct client IP in acl

Amos Jeffries
Administrator
On 10/07/20 2:10 pm, Orion Poplawski wrote:

> On 7/9/20 6:50 PM, Amos Jeffries wrote:
>> On 10/07/20 9:54 am, Orion Poplawski wrote:
>>> Hello -
>>>
>>>    We're using a setup like this:
>>>
>>> client -> e2guardian -> squid -> internet
>>>
>>> e2guardian is providing filtering and SSL inspection.  Currently we only
>>> allow access to e2guardian from our internal network.  Currently we
>>> enforce access to squid come from localhost, except for some specific
>>> sites which do not work with SSL inspection.
>>>
>>> Then we allow:
>>>
>>> client -> squid -> internet
>>>
>>> this is based on the (non-forwarded) client IP.
>>>
>>> We would like to open up access to e2g from the internet but require
>>> authentication in that case.
>>
>> Okay.
>>
>>>    This would require the use of forwarded
>>> IPs so the squid could distinguish between them (e2g does not do auth
>>> directly - it lets squid handle that).  But then this breaks our config
>>> above because we no longer can distinguish between connections from e2g
>>> and direct ones.
>>
>>
>> How do you come to that conclusion?
>
> I don't know how to distinguish between connections that go through e2g
> and connections that do not.  Currently anything with a client IP of
> localhost has gone through e2g.  Anything with a different client IP has
> not.  If I use the X-Forwarded-As IP to distinguish between internal and
> external (for auth purposes) I no longer know how to distinguish between
> forwarded connections and non-forwarded connections.  Is there a
> forwarded flag that can be used as an acl?  I couldn't see anything in
> the acl docs.

The purpose of XFF feature is to see the IP beyond the e2g relay.
Properly configured Squid will have no problem determining the
difference between LAN and WAN IP ranges.

Configure e2g to set the header (if needed, it may do so by default).
Then make the following squid.conf adjustments to have only the
non-localnet clients authenticate.


>
>> What is your Squid version?
>
> 3.5.20 (EL7), though I may be able to update 4.4 (EL8).
>
>> What is your current squid.conf contents?
>
> This part of our ansible template.  Essentially we have a list of hosts
> in "Allowed_SSL_Hosts" and "Allowed_HTTP_Hosts: that we allow any client
> to connect directly through squid to (via HTTPS/HTTP respectively).
>
> acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
>
> acl SSL_ports port 443
> acl SSL_Ports port 563          # smtps
> acl SSL_Ports port 5228         # mtalk.google.com
> acl Safe_ports port 80          # http
> acl Safe_ports port 21          # ftp
> acl Safe_ports port 443         # https
> acl CONNECT method CONNECT
>
> acl Allowed_SSL_Hosts ssl::server_name {{ ansible_nodename }}
>
> # We can't MITM these, but allow them through the proxy
> {% for domain in allowed_ssl_hosts %}
> acl Allowed_SSL_Hosts ssl::server_name {{ domain }}
> {% endfor %}
> # Some hosts present problems for e2guardian for unknown reasons
> {% for domain in allowed_http_hosts %}
> acl Allowed_HTTP_Hosts dstdomain {{ domain }}
> {% endfor %}
>
> # Deny requests to certain unsafe ports
> http_access deny !Safe_ports
>
> # macOS Catalina is using CONNECT to gs.apple.com:80
> http_access allow localnet Allowed_HTTP_Hosts
>
> # Deny CONNECT to other than secure SSL ports
> http_access deny CONNECT !SSL_ports
>
> # Only allow cachemgr access from localhost
> http_access allow localhost manager
> http_access deny manager
>
> # 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
>
> # All traffic should be coming via e2guardian on localhost

Instead use:

 # only use the XFF header(s) set by e2guardian
 follow_x_forwarded_for allow localhost
 follow_x_forwarded_for deny all

Which updates the IP Squid sees on traffic coming through e2g.


>
> # Allow certain sites to be connected to directly
> http_access allow CONNECT localnet Allowed_SSL_Hosts

Move this down ...

>
> # Allow some users/applications to connect from outside
> auth_param digest realm "NWRA Proxy"
> auth_param digest program /usr/lib64/squid/digest_file_auth
> /etc/squid/passwd
> # freshclam only supports basic auth -
> https://bugzilla.clamav.net/show_bug.cgi?id=12468
> auth_param basic realm "NWRA Proxy"
> auth_param basic program /usr/lib64/squid/basic_ncsa_auth
> /etc/squid/htpasswd
> acl authenticated_users proxy_auth REQUIRED
> http_access allow CONNECT authenticated_users Allowed_SSL_Hosts

Instead use:
  http_access deny !localnet !authenticated_users


... to here:
  http_access allow CONNECT Allowed_SSL_Hosts

> # freshclam 0.101.5 uses HTTP
> http_access allow authenticated_users Allowed_HTTP_Hosts
>

Instead use:
  http_access allow !localnet Allowed_HTTP_Hosts


> # And finally deny all other access to this proxy
> http_access deny all
>
> Thank you,
>
>   Orion
>


HTH
Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Explicitly use direct client IP in acl

Orion Poplawski
On 7/9/20 10:47 PM, Amos Jeffries wrote:

> On 10/07/20 2:10 pm, Orion Poplawski wrote:
>> On 7/9/20 6:50 PM, Amos Jeffries wrote:
>>> On 10/07/20 9:54 am, Orion Poplawski wrote:
>>>> Hello -
>>>>
>>>>    We're using a setup like this:
>>>>
>>>> client -> e2guardian -> squid -> internet
>>>>
>>>> e2guardian is providing filtering and SSL inspection.  Currently we only
>>>> allow access to e2guardian from our internal network.  Currently we
>>>> enforce access to squid come from localhost, except for some specific
>>>> sites which do not work with SSL inspection.
>>>>
>>>> Then we allow:
>>>>
>>>> client -> squid -> internet
>>>>
>>>> this is based on the (non-forwarded) client IP.
>>>>
>>>> We would like to open up access to e2g from the internet but require
>>>> authentication in that case.
>>>
>>> Okay.
>>>
>>>>    This would require the use of forwarded
>>>> IPs so the squid could distinguish between them (e2g does not do auth
>>>> directly - it lets squid handle that).  But then this breaks our config
>>>> above because we no longer can distinguish between connections from e2g
>>>> and direct ones.
>>>
>>>
>>> How do you come to that conclusion?
>>
>> I don't know how to distinguish between connections that go through e2g
>> and connections that do not.  Currently anything with a client IP of
>> localhost has gone through e2g.  Anything with a different client IP has
>> not.  If I use the X-Forwarded-As IP to distinguish between internal and
>> external (for auth purposes) I no longer know how to distinguish between
>> forwarded connections and non-forwarded connections.  Is there a
>> forwarded flag that can be used as an acl?  I couldn't see anything in
>> the acl docs.
>
> The purpose of XFF feature is to see the IP beyond the e2g relay.
> Properly configured Squid will have no problem determining the
> difference between LAN and WAN IP ranges.
>
> Configure e2g to set the header (if needed, it may do so by default).
> Then make the following squid.conf adjustments to have only the
> non-localnet clients authenticate.
>
>
>>
>>> What is your Squid version?
>>
>> 3.5.20 (EL7), though I may be able to update 4.4 (EL8).
>>
>>> What is your current squid.conf contents?
>>
>> This part of our ansible template.  Essentially we have a list of hosts
>> in "Allowed_SSL_Hosts" and "Allowed_HTTP_Hosts: that we allow any client
>> to connect directly through squid to (via HTTPS/HTTP respectively).
>>
>> acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
>> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
>>
>> acl SSL_ports port 443
>> acl SSL_Ports port 563          # smtps
>> acl SSL_Ports port 5228         # mtalk.google.com
>> acl Safe_ports port 80          # http
>> acl Safe_ports port 21          # ftp
>> acl Safe_ports port 443         # https
>> acl CONNECT method CONNECT
>>
>> acl Allowed_SSL_Hosts ssl::server_name {{ ansible_nodename }}
>>
>> # We can't MITM these, but allow them through the proxy
>> {% for domain in allowed_ssl_hosts %}
>> acl Allowed_SSL_Hosts ssl::server_name {{ domain }}
>> {% endfor %}
>> # Some hosts present problems for e2guardian for unknown reasons
>> {% for domain in allowed_http_hosts %}
>> acl Allowed_HTTP_Hosts dstdomain {{ domain }}
>> {% endfor %}
>>
>> # Deny requests to certain unsafe ports
>> http_access deny !Safe_ports
>>
>> # macOS Catalina is using CONNECT to gs.apple.com:80
>> http_access allow localnet Allowed_HTTP_Hosts
>>
>> # Deny CONNECT to other than secure SSL ports
>> http_access deny CONNECT !SSL_ports
>>
>> # Only allow cachemgr access from localhost
>> http_access allow localhost manager
>> http_access deny manager
>>
>> # 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
>>
>> # All traffic should be coming via e2guardian on localhost
>
> Instead use:
>
>  # only use the XFF header(s) set by e2guardian
>  follow_x_forwarded_for allow localhost
>  follow_x_forwarded_for deny all
>
> Which updates the IP Squid sees on traffic coming through e2g.
>
>
>>
>> # Allow certain sites to be connected to directly
>> http_access allow CONNECT localnet Allowed_SSL_Hosts
>
> Move this down ...
>
>>
>> # Allow some users/applications to connect from outside
>> auth_param digest realm "NWRA Proxy"
>> auth_param digest program /usr/lib64/squid/digest_file_auth
>> /etc/squid/passwd
>> # freshclam only supports basic auth -
>> https://bugzilla.clamav.net/show_bug.cgi?id=12468
>> auth_param basic realm "NWRA Proxy"
>> auth_param basic program /usr/lib64/squid/basic_ncsa_auth
>> /etc/squid/htpasswd
>> acl authenticated_users proxy_auth REQUIRED
>> http_access allow CONNECT authenticated_users Allowed_SSL_Hosts
>
> Instead use:
>   http_access deny !localnet !authenticated_users
>
>
> ... to here:
>   http_access allow CONNECT Allowed_SSL_Hosts
>
>> # freshclam 0.101.5 uses HTTP
>> http_access allow authenticated_users Allowed_HTTP_Hosts
>>
>
> Instead use:
>   http_access allow !localnet Allowed_HTTP_Hosts
>
>
>> # And finally deny all other access to this proxy
>> http_access deny all

IIUIC - this mainly gives me:

http_access deny !localnet !authenticated_users
http_access allow CONNECT Allowed_SSL_Hosts
http_access allow !localnet Allowed_HTTP_Hosts
http_access deny all

But this will only allow connections to the sites listed in Allowed_SSL_Hosts
or Allowed_HTTP_Hosts (from remote) and not to anything else.  This is not
what I want.  I want to allow access to any site from a connection that is
forwarded from e2g.

--
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       [hidden email]
Boulder, CO 80301                 https://www.nwra.com/
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Explicitly use direct client IP in acl

Amos Jeffries
Administrator
On 11/07/20 4:44 am, Orion Poplawski wrote:

>
> IIUIC - this mainly gives me:
>
> http_access deny !localnet !authenticated_users
> http_access allow CONNECT Allowed_SSL_Hosts
> http_access allow !localnet Allowed_HTTP_Hosts
> http_access deny all
>
> But this will only allow connections to the sites listed in Allowed_SSL_Hosts
> or Allowed_HTTP_Hosts (from remote) and not to anything else.  This is not
> what I want.  I want to allow access to any site from a connection that is
> forwarded from e2g.
>


Yes. The earlier stated policy was:

> We would like to open up access to e2g from the internet but require
> authentication in that case.

I provided the rule adjustment to add that to your existing
restrictions. As you can see the LAN is represented by localnet ACL and
the WAN clients by !localnet.


To match traffic arriving from a specific client application (aka e2g)
you have a couple of options.

a) Simplest is to use a dedicated http_port for that application. The
myportname ACL can then match all that applications traffic.
 This is quick and easy but does not prevent other applications sending
traffic to the port. Additional firewall settings are needed to prevent
that.


b) The system QoS service marking packets coming out of e2g. The
clientside_mark / clientside_tos ACLs can match this marking.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users