Re: Client IP PTR lookup on connect

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Client IP PTR lookup on connect

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", &sin6_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", &sin6_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\6\0\1\0\0\t[\0/\vh1-f5lb01-s\300\21\nhostmaster\300\21\0\0\0034\0\0\250\300\0\0\3\204\0\22u\0\0\1Q\200",
16384, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("10.20.10.18")}, [28->16]) = 112
recvfrom(10, 0x556dee0c0020, 16384, 0, 0x556df02562c0, [28]) = -1 EAGAIN
(Resource temporarily unavailable)
epoll_wait(6, [{EPOLLIN, {u32=10, u64=10}}], 4096, 626) = 1
recvfrom(10,
"!6\201\200\0\1\0\3\0\0\0\0\2i5\1c\4eset\3com\0\0\1\0\1\300\f\0\5\0\1\0\5\315\351\0\n\2i5\4cwip\300\21\300+\0\1\0\1\0\0\0\36\0\4[\344\245,\300+\0\1\0\1\0\0\0\36\0\4[\344\247.",
16384, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("10.20.10.18")}, [28->16]) = 85
..

anybody has any idea why is this happening?

thanks

michal



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

Re: Client IP PTR lookup on connect

Amos Jeffries
Administrator
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Client IP PTR lookup on connect

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
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users

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