Re: [squid-users] Re: how can i get the localport in forward proxy mode?

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sun, 13 Jul 2014 03:51:29 +1200

On 13/07/2014 2:35 a.m., freefall12 wrote:
> this is my iptables rules
>
> iptables -A PREROUTING -p tcp -m tcp --dport 30000:60000 -j REDIRECT
> --to-ports 50000
>
> port 5000 is the squid's listing port.
>
> What i want to do is to assign each user an unique port number and rely upon
> the port number in the access log for accounting.
>
> OK,the procedures will be something like this:
>
> 1,When an user register an account at the site, assign the user a random
> port number and associate it to the username in database
> 2,Open the port using iptables
> 3,use the %>lp symbol to record the connected port number in access log.
> 4,Parse the access log and insert relevant accounting data into the database
> 5,Automatically ban ip if port scanning is detected
>
> i'm stuck at the step 3 as i'm unable to get the connected port number in
> forward proxy mode
>
> Do you think this can work reliably in reality?

That REDIRECT is a NAT rule. It will definitely need the "intercept"
option on Squid listening port to fetch the correct client destination
details as the only thing the OS gives to Squid is its own port 50000.
Just like you found.

Getting the traffic into Squid is not the biggest issue though. Since
you are using NAT to do it you will then face all the traffic
interception security checks which verify the TCP destination IP address
the client is going to matches the Host header rDNS records. If they
dont match, Squid will use the provided IP address directly - which in
your case will loop back at itself.

Alternatives:

You could use the ext_session_acl helper. It was designed for this type
of user management. In active mode it presents a splash page for user
login before access is granted to them by configured signature for a while.

The newer ext_session_sql_acl helper is similar, but depends entirely on
an external identification/login system updating the SQL database which
it checks for a configured client signature.

NP: the default signature for these session helpers in demos is usually
IP address. But there is no technical reason it has to be.
 In your current plan it is the destination port, but it could just as
easily be the src-IP and User-Agent header pair for almost unique user
identification.

You could also re-build Squid with a larger definition for
MAXTCPLISTENPORTS in src/anyp/PortCfg.h and configuring multiple
http_port lines. But this set of ports is scanned sequentially at least
every 10ms, which could slow down your proxy noticably if the set was
particularly large.

You could use IPv6 with EUI-64 ACL verification and require your clients
to use their SLAAC IPv6 addresses to contact you. Can be tricky to
ensure the right address is used though.

Amos
Received on Sat Jul 12 2014 - 15:51:51 MDT

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2014 - 12:00:06 MDT