strange connection attempts

Guy P. guy at device.dyndns.org
Mon Apr 14 05:18:03 PDT 2003


At 13:31 14/04/2003, GiZmen <gizmen at pals.one.pl> wrote:
>I have turned on sysctls variables:
>net.inet.tcp.log_in_vain: 1
>net.inet.udp.log_in_vain: 1
>
>And i have plenty of strange connection attempts on udp protocol
>
>  Connection attempt to UDP xx.xx.x.xxx:55414 from 
> 192.43.172.34:53
>  Apr 13 23:56:53 pals /kernel: Connection attempt to UDP 
> xx.xx.x.xxx:55414 from 192.43.172.34:53
>  Connection attempt to UDP xx.xx.x.xxx:12545 from 
> 192.42.93.36:53
>  Apr 13 23:56:54 pals /kernel: Connection attempt to UDP xx.xx..xxx:12545 
> from 192.42.93.36:53
>  Connection attempt to UDP xx.xx.x.xxx:44308 from 192.42.93.36:53
>
>i know that those connections are from dns but why kernel logs such thing.
>I have statufull firewall and all trafic to any port on UDP protocol are 
>deny and
>only those UDP datagrams from my resolver are passed back through dynamics 
>rules.
>These connections are caused by returned queruies from dns servers.
>Is it normal to have such type connection attempts ?
>
>Can anybody help me solve my problem.

Yes it is normal. What happens is :

1) your system have to resolve a name. So it send querys to all(?) the 
multiple NS listed in /etc/resolv.conf
2) as soon it got the reply from one of the queried NS, it unbind the udp 
socket(s) it was listening on.
3) the slower-answering NS packets are still forwarded back by your 
statefull firewall, but as your resolver process is no longer listening, 
these latter replys are logged as unattended connection attempts.

This could also happen if some timeout value was reached.

Take this just as a wild guess on my side, as i'm not familiar with the 
internal resolver lib intrinsecs.

Nothing to care about as long these "connection attempts" come from the NS 
that are listed in your resolv.conf

If you mind about these "false positives", i'd suggest using a log analyzer 
utility such as /usr/ports/security/logcheck and instruct it to ignore 
these log entries.

--
         Guy




More information about the freebsd-security mailing list