Re: [squid-users] Client IP PTR lookup on connect

2020-05-19 Thread Michal Bruncko

Hi Amos

thank you for very valuable response. I can confirm that amending 
default url_rewrite_extras value did the trick!


thanks
michal

On 5/17/2020 12:36 PM, Amos Jeffries wrote:

On 14/05/20 1:44 am, Michal Bruncko wrote:

Hello guys

following the original thread "[squid-users] Squid 4.9 Client IP PTR
lookup on connect"

I am observing exactly same bahavour on
squid-4.4-8.module_el8.1.0+197+0c39cdc8.x86_64 on CentOS 8.

Certainly 4.4 is older than 4.9.



At first I was suspecting some squid module (auth helper
(gssapi/ntlm/basic), URL rewriter) or syslog (which we use for sending
access logs to remote server) but those DNS queries are coming directly
from squid process (same as the one doing standard forward DNS lookups).

The URL-rewriter input includes the rDNS name of the client IP. I expect
your Squid is trying to fetch that information to send the re-writer.



write(16,
"http://i5.c.eset.com/v1/auth/851A4855CEEAB5292C10/updlist/0/eid/7033368/lid/7033484
2001:4118:804:f000::103/2001:4118:804:f000::"..., 179) = 179

If that information is not actually needed by your re-writer, then
configure the url_rewrite_extras directive to alter what gets sent.


Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Client IP PTR lookup on connect

2020-05-19 Thread Amos Jeffries
On 14/05/20 1:44 am, Michal Bruncko wrote:
> Hello guys
> 
> following the original thread "[squid-users] Squid 4.9 Client IP PTR
> lookup on connect"
> 
> I am observing exactly same bahavour on
> squid-4.4-8.module_el8.1.0+197+0c39cdc8.x86_64 on CentOS 8.

Certainly 4.4 is older than 4.9.


> At first I was suspecting some squid module (auth helper
> (gssapi/ntlm/basic), URL rewriter) or syslog (which we use for sending
> access logs to remote server) but those DNS queries are coming directly
> from squid process (same as the one doing standard forward DNS lookups).

The URL-rewriter input includes the rDNS name of the client IP. I expect
your Squid is trying to fetch that information to send the re-writer.


> write(16,
> "http://i5.c.eset.com/v1/auth/851A4855CEEAB5292C10/updlist/0/eid/7033368/lid/7033484
> 2001:4118:804:f000::103/2001:4118:804:f000::"..., 179) = 179

If that information is not actually needed by your re-writer, then
configure the url_rewrite_extras directive to alter what gets sent.


Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Client IP PTR lookup on connect

2020-05-13 Thread Michal Bruncko

Hello guys

following the original thread "[squid-users] Squid 4.9 Client IP PTR 
lookup on connect"


I am observing exactly same bahavour on 
squid-4.4-8.module_el8.1.0+197+0c39cdc8.x86_64 on CentOS 8.
Almost for each client connection to squid port 3128 is squid doing a 
client IP PTR resolution request. I am not using "srcdomain"-based ACLs 
nor icap_log setting.
Normally I wouldnt notice this, but today our proxy server get flooded 
by huge amount of requests (which were actually all denied on this 
proxy) coming from awesome nvidia control panel/tool (immediate 
connection request repeat after rejection from proxy) from newly 
deployed workstations and this flood of proxy requests caused another 
flood of DNS PTR lookups of randomized IPv6 client IPs which werent in 
reverse zones at all.
At first I was suspecting some squid module (auth helper 
(gssapi/ntlm/basic), URL rewriter) or syslog (which we use for sending 
access logs to remote server) but those DNS queries are coming directly 
from squid process (same as the one doing standard forward DNS lookups).


here is snip from strace of squid where you can see incoming connection 
from client and basically immediate DNS PTR lookup


accept(144, {sa_family=AF_INET6, sin6_port=htons(58574), 
inet_pton(AF_INET6, "2001:4118:804:f000::103", _addr), 
sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 12
getsockname(12, {sa_family=AF_INET6, sin6_port=htons(3128), 
inet_pton(AF_INET6, "2001:4118:804:f000::200", _addr), 
sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0

fcntl(12, F_GETFD)  = 0
fcntl(12, F_SETFD, FD_CLOEXEC)  = 0
fcntl(12, F_GETFL)  = 0x2 (flags O_RDWR)
fcntl(12, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
sendto(10, 
"l\370\1\0\0\1\0\0\0\0\0\0\0013\0010\0011\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\1f\0014\0010\18\0010\18\0011\0011\0014\0011\0010\0010\0012\3ip6\4arpa\0\0\f\0\1", 
90, 0, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("10.20.10.18")}, 16) = 90
epoll_ctl(6, EPOLL_CTL_ADD, 12, {EPOLLIN|EPOLLERR|EPOLLHUP, {u32=12, 
u64=12}}) = 0

epoll_wait(6, [{EPOLLIN, {u32=12, u64=12}}], 4096, 987) = 1
read(12, "GET 
http://i5.c.eset.com:80/v1/auth/851A4855CEEAB5292C10/updlist/0/eid/7033368/lid/7033484 
HTTP/1.1\r\nHost: i5.c.eset.com:80\r\nCon"..., 4096) = 181
sendto(10, 
"\342|\1\0\0\1\0\0\0\0\0\0\0013\0010\0011\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\1f\0014\0010\18\0010\18\0011\0011\0014\0011\0010\0010\0012\3ip6\4arpa\0\0\f\0\1", 
90, 0, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("10.20.10.18")}, 16) = 90
epoll_ctl(6, EPOLL_CTL_MOD, 16, {EPOLLIN|EPOLLOUT|EPOLLERR|EPOLLHUP, 
{u32=16, u64=16}}) = 0

epoll_wait(6, [{EPOLLOUT, {u32=16, u64=16}}], 4096, 972) = 1
write(16, 
"http://i5.c.eset.com/v1/auth/851A4855CEEAB5292C10/updlist/0/eid/7033368/lid/7033484 
2001:4118:804:f000::103/2001:4118:804:f000::"..., 179) = 179

epoll_wait(6, [{EPOLLIN|EPOLLOUT, {u32=16, u64=16}}], 4096, 970) = 1
read(16, "\n", 32767)   = 1
epoll_ctl(6, EPOLL_CTL_MOD, 16, {EPOLLIN|EPOLLERR|EPOLLHUP, {u32=16, 
u64=16}}) = 0
sendto(10, "!6\1\0\0\1\0\0\0\0\0\0\2i5\1c\4eset\3com\0\0\1\0\1", 31, 0, 
{sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("10.20.10.18")}, 16) = 31
sendto(10, "\367$\1\0\0\1\0\0\0\0\0\0\2i5\1c\4eset\3com\0\0\34\0\1", 31, 
0, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("10.20.10.18")}, 16) = 31

epoll_wait(6, [{EPOLLIN, {u32=10, u64=10}}], 4096, 970) = 1
recvfrom(10, 
"l\370\205\200\0\1\0\1\0\0\0\0\0013\0010\0011\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\1f\0014\0010\18\0010\18\0011\0011\0014\0011\0010\0010\0012\3ip6\4arpa\0\0\f\0\1\300\f\0\f\0\1\0\0\4\260\0\23\6server\2ad\4example\2sk\0", 
16384, 0, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("10.20.10.18")}, [28->16]) = 121
recvfrom(10, 0x556dee0c0020, 16384, 0, 0x556df02562c0, [28]) = -1 EAGAIN 
(Resource temporarily unavailable)

epoll_wait(6, [{EPOLLIN, {u32=10, u64=10}}], 4096, 762) = 1
recvfrom(10, 
"\342|\205\200\0\1\0\1\0\0\0\0\0013\0010\0011\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\0010\1f\0014\0010\18\0010\18\0011\0011\0014\0011\0010\0010\0012\3ip6\4arpa\0\0\f\0\1\300\f\0\f\0\1\0\0\4\260\0\23\6server\2ad\4example\2sk\0", 
16384, 0, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("10.20.10.18")}, [28->16]) = 121
recvfrom(10, 0x556dee0c0020, 16384, 0, 0x556df02562c0, [28]) = -1 EAGAIN 
(Resource temporarily unavailable)

epoll_wait(6, [{EPOLLIN, {u32=10, u64=10}}], 4096, 635) = 1
recvfrom(10, 
"\367$\201\200\0\1\0\1\0\1\0\0\2i5\1c\4eset\3com\0\0\34\0\1\300\f\0\5\0\1\0\5\315\351\0\n\2i5\4cwip\300\21\300.\0