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