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

Amos Jeffries wrote
> 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

Sorry, i don't know much about iptables.what other iptables rules can i use
to get the correct client destination
details?

The 2 alternatives you've suggested appear to be not fit for my plan.

To my knowledge, ext_session_acl will still need a page for
reauthentication, which doesn't work with mobile apps. is that correct?
Also, changing the port range definition a larger may not be a practical
solution when users grow to hundreds or thousands.

--
View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/how-can-i-get-the-localport-in-forward-proxy-mode-tp4666888p4666892.html
Sent from the Squid - Users mailing list archive at Nabble.com.